Date: Thu, 14 Oct 1999 10:39:35 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Richard Dawe cc: DJGPP workers Subject: Re: /dev/zero support In-Reply-To: <3804C701.347EB2A0@tudor21.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.