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

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

- Raw text -