Re: PROPOSAL: dot-proc interface [was: /proc stuff]

[Erik Andersen]

On Tue Nov 06, 2001 at 05:47:53PM -0500, [e-mail] wrote:
> In article <[e-mail]> you wrote:
> > Sorry, no doughnut for you.  drivers/block/genhd.c:
> 
> >    #ifdef CONFIG_PROC_FS
> >    int get_partition_list(char *page, char **start, off_t offset, int count)
> >        char buf[64];
> > so each /proc/partitions line maxes out at 63 bytes.  So not only
> > is there no overflow, I am providing 16 extra bytes of padding.
> 
> "code poet?"  you've plucked an 80 from the air.  regardless of what the

Yup, you are right.  You found me out.  I'm a complete impostor
and I know nothing about programming because I spent the exactly
4 seconds to write a simple example without first researching the
underlying interface.  Know why?  Because it was an _example_,
not a dissertation on string processing.  If I was actually going
to write that code, I would have spent the extra two minute it
would have taken to read the kernel source first.  Yes, fixed
buffers suck.  But that is the current interface, so get over it
and get over the pointless ad hominem attacks. 

> constant...", but i work in network security).  others, however,
> may not be so skilled as you, and what of when they're writing
> your server?

Then I should be spending more time interviewing so I don't hire
dolts, and I would spend more time auditing their code and
teaching them how to program. 

I actually avoid using /proc as much as possible in all my code
(I even wrote a patch to replace /proc with a char device about a
year ago, rejected of course for the same reasons Linus expressed
on this thread).  There are many valid reasons why /proc sucks
(especially for embedded systems).  But I don't consider the
ASCII-is-hard-to-parse argument valid.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--