Sender: richdawe AT bigfoot DOT com
Message-ID: <3808B8F0.754C8048@tudor21.net>
Date: Sat, 16 Oct 1999 18:42:08 +0100
From: Richard Dawe <richdawe AT bigfoot DOT com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Re: /dev/zero support
References: <Pine DOT SUN DOT 3 DOT 91 DOT 991014103916 DOT 26124E-100000 AT is> <199910142216 DOT SAA04636 AT envy DOT delorie DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

DJ Delorie wrote:
> > 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.
<snip>
> 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 think /dev/zero support code could be linked in automatically by having
the FSEXT list point at the relevant FSEXT function - see
src/libc/fsext/fse_open.c - set FuncList to point to the /dev/zero FSEXT.
I think that since this module is always linked in, it will cause the
/dev/zero code to link too.

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

In that case I will use my original FSEXT approach, unless there are any
more thoughts.

Thanks, bye,

-- 
Richard Dawe
richdawe AT bigfoot DOT com ICQ 47595498 http://www.bigfoot.com/~richdawe/