Re: Suggested dual human/binary interface for proc/devfs

From: Richard Gooch (rgooch@ras.ucalgary.ca)
Date: Tue Apr 04 2000 - 19:36:57 EST


H. Peter Anvin writes:
> Followup to: <Pine.GSO.4.10.10004041801380.12544-100000@weyl.math.psu.edu>
> By author: Alexander Viro <viro@math.psu.edu>
> In newsgroup: linux.dev.kernel
> >
> > Richard, it's a pure bullshit.
> > int foo(char **p) {
> > char *s=*p;
> > int i;
> > for(i=0;isdigit(*s);i*=10,i+=*s++-'0')
> > ;
> > *p=s;
> > return i;
> > }
> > And yes, isdigit() is there. It's _one_ function. If you think that it's
> > hard - tough luck, it isn't. Comparison with Perl is somewhat, erm,
> > strained. We are talking about 64 bytes - compile with normal kernel flags
> > and use size(1). 4 cache lines. Eh, wait - what was that thing in lib/*.c?
> > <grepping> Aha, simple_strtoul(). In lib/vsprintf.c. So it's _ZERO_ extra
> > code. Where's the bloat in question? Sure, we can copy it into every
> > source file. The other question being, why would we do that?
> >
>
> If it's in kernel memory, you can use simple_stroul(). If not, you
> have to go get_user() and check the return code for every byte.
>
> I do think we need some canned functions to parse standard ASCII
> formats *in user memory*. With standard formats I mean integer
> arrays and escapable strings.

I agree. The current sysctl situation is a dog's breakfast. If we had:

- a kernel-side API for reading and writing ASCII

- supported mixed data types

- did not generate a lot of kernel bloat

- a corresponding user-side API for reading and writing ASCII (maybe
  even the same code base)

- an efficient implementation such that, for example, top didn't
  consume so much CPU time

then we'd be in much better shape, and we might be able to reasonably
get away without a binary interface. And there is one other
requirement:

WE NEED TO BE FORCEFUL ABOUT MAINTAINING A CONSISTENT INTERFACE SO
THAT WE DON'T BREAK USER-SPACE CODE. IF A "SPELLING" PATCH GOES IN,
THE PATCH AUTHOR SHOULD BE RELENTLESSLY HOUNDED UNTIL IT'S FIXED.
"Fixed" means: old user-space code still works.

If the API could be made tolerant of (resonable) changes to the
interface (such as a new parameter in a "structure"), this would help
a lot. But spelling "fixes" should be absolutely banned!

Ideally, the API would allow you to pass a structure pointer which
contains the data to be read/written. A structure is the natural way
of dealing with mixed data. This would mean you'd need to pass in a
descriptor as well, when converting.

                                Regards,

                                        Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:13 EST