Alexander Viro writes:
>
>
> On Tue, 4 Apr 2000, Richard Gooch wrote:
>
> > > echo 57600,8,n,1 > /dev/serial/ttyS0ctl should work.
> >
> > Well, time to throw back one of the old anti-devfs arguments:
> > bloat. Parsing ASCII is a lot harder than dereferencing structure
> > fields.
>
> What? Excuse me, have you ever written atoi() - by hands, as a
> trivial exercise? It's _one_ function. A lot harder?
Nope. I write all my parses in assmbler. It's faster that way.
Duh! Of course I've used atoi(3). Countless times. Did you really need
to ask it?
> > Let's also distinguish between ASCII *output* and input. ASCII output
> > makes some sense, but to force everything to be input in ASCII will
> > just bloat the kernel. Let's put perl into the kernel too so that
> > parsing ASCII will be easier.
>
> Richard, it's a pure bullshit.
Such a nice expression.
> 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?
The reality is that real input is more complicated than you
describe. For a start, your code doesn't handle mixed
datatypes. Something that a structure handles very well.
It's a fundamental fact that ASCII parsers require more code (even
with atoi(3) and similar functions) than direct structure accessing.
> > Frankly, I'm surprised that someone hasn't submitted a patch to make
> > some procfs file output the right escape codes to generate a
> > multi-coloured output line.
> > "But it looks so *pretty*".
>
> BS. It's not about "pretty", it's about "doesn't depend on magic
> constants, is bytesex-independednt and can be used with any regular
> UNIX tools, starting with echo".
I'm not saying ASCII interfaces are there to be pretty. I've already
acknowledged that they have good reason. I'm not at all suggesting
that we have binary only interfaces. My point about "pretty" is that
there is too much temptation to go in and beautify ASCII output. It's
happened multiple times. If the ASCII interfaces were only read by
humans, it wouldn't be an issue. But they're read by computers too.
A binary interface doesn't have all the problems you're trying to
suggest:
- no magic constants needed
- byte ordering doesn't matter since we're reading from the same
machine
- regular Unix tools can use the ASCII interface, specialised
programmes can use the binary interface.
Binary interfaces are the natural interface for programmes. ASCII
interfaces are the natural interface for humans. We need to support
both.
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