Date: Thu, 14 Oct 1999 18:16:12 -0400
Message-Id: <199910142216.SAA04636@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
CC: richdawe AT bigfoot DOT com
In-reply-to: <Pine.SUN.3.91.991014103916.26124E-100000@is> (message from Eli
	Zaretskii on Thu, 14 Oct 1999 10:39:35 +0200 (IST))
Subject: Re: /dev/zero support
References:  <Pine DOT SUN DOT 3 DOT 91 DOT 991014103916 DOT 26124E-100000 AT is>
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


> > 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.

I originally designed FSEXT to handle stuff like this, though.  The
idea was that the user could obtain and link in a variety of
third-party libraries to add unix emulation to their programs as
needed.  For example, a tcp/ip library would provide socket() but
would also use a FSEXT to do I/O to open sockets.  Neither libc nor
the application should need to know about these fsexts, and multiple
fsexts should work.  The only catch is that if you use a library that
*only* provides an fsext, you really need to provide it as a single
object rather than an archive, else the linker won't link it in (it
doesn't resolve any additional symbols, the way socket() would for a
tcp/ip library).

I definitely want to avoid adding hooks in libc for things that can be
done with fsexts.  The exceptions so far are for obviously common
things, like /dev/null and a few other renames.