On Tue, 4 Apr 2000, Richard Gooch wrote:
> Manuel Estrada writes:
> >
> > Hello, I am no kernel expert, but for some time an idea has
> > been floating in my mind since I read someone criticizing proc for
> > being human readable and time consuming to read by top or any other
> > program.
> >
> > Well, what about having a human interface for humans and a
> > binary interface for programs, using some flag to to open (2) to
> > select it, something which wouldn't have a meaning within those files,
> > the perfect one would be something like O_BINARY, which also wouldn't
> > have any meaning otherwise, but that one doesn't exist. Then maybe
> > O_LARGEFILE, O_SYNC, O_TRUNC, O_APPEND... Well, I don't realy know if
> > this are good candidates.
> >
> > And also, not all files would need the dual interface, the
> > opening program should know if a certain file supported it and also
> > the format of the interface.
>
> Have a look at the MTRR driver: arch/i386/kernel/mtrr.c
>
> We don't need another flag to open(2). Just make read(2) provide
> human-readable data, and ioctl(2) computer-readable data.
Richard, it's an _absolute_ BS. Sorry, but ioctl() on procfs is
ridiculous - the whole thing was created to avoid that sort of interfaces.
Introducing new ioctls is the last resort - remember, this syscall was
invented as an explicit barf-bag. And was abandoned by authors, BTW. Now,
we can't afford getting rid of all ioctls, but we can avoid adding more,
erm, matter into that barf-bag.
-
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:12 EST