Manuel Estrada <ranty@soon.com> writes:
: 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.
What would be the default ? There are cases where choosing either
would be unfortunate. If the binary interface is only available to
programs that know how to insist upon it, the benefit seems reduced (I
can't use an arbitrary tool with the binary interface). A default of
binary would cause much consternation I suppose :-)
How big a problem is this in the real world ? Perhaps a naming
convention to indicate text/binary would be best, together with some
tools to ensure that providers of /proc data don't have to provide
extra code to support both interfaces.
dme.
-
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:14 EST