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

- Raw text -