Mail Archives: djgpp-workers/1999/10/14/04:59:12
On Wed, 13 Oct 1999, Richard Dawe wrote:
> I was recently thinking of adding /dev/zero via a FSEXT to DJGPP.
I think supporting /dev/zero is a good idea, but I don't think FSEXT
is the way to do it.
The problem with FSEXT is that if the library installs an FSEXT hook,
it makes it hard for applications to install another hook. They need
to go to extra trouble to (1) detect that a hook is already installed,
and (2) to chain to the library hook if the application's hook doesn't
handle the service.
Even more importantly, the hooks are typically installed in a function
declared with __attribute__((constructor)), which makes it next to
impossible to control the order in which the hooks are installed: it
is the order in which the linker sees such functions. Since the
linker links application code before the library, typically you will
have the application's hook be installed first, and only then the
library's one--the exact opposite of what you need.
FSEXT is meant to be used by the applications, not by libraries. If
we want it to be used by libraries, it will have to be rewritten, at
least to some extent.
> I reasoned that /dev/null was currently implemented in this way.
No. /dev/null (and all other /dev/* magic) is implemented in the
function that puts file names into the transfer buffer. The
assumption here is that any /dev/* string names either a file or a
device, so we only need a simple name translation: when they pass
/dev/null, the transfer buffer actually gets NUL, but we do nothing
about the system call that uses the name. If I understand correctly,
this trick won't work for /dev/zero.
I suggest to use the same method used by termios: introduce a special
hook that I/O functions know about, and which gets called after user's
FSEXTs, but before the DOS function calls. It is possible that you
can use the same hook already used by termios, just extend it with
some flags and add the calls that implement /dev/zero support.
Another, possibly simpler, alternative would be to make /dev/zero be
mapped to the null device, the same way /dev/null is handled, but mark
the handle in some special way, so that _read will return a block of
zeroes instead of actually reading.
> A grep of the DJGPP libc sources didn't yield anything that looked like
> /dev/null support.
Somehow, you didn't grep it all, or maybe you looked for a literal
"/dev/null" (you won't find it). The support for /dev/* is in
src/libc/dos/io/putpath.c.
- Raw text -