Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3A50E72B.2B422C95@phekda.freeserve.co.uk>
Date: Mon, 01 Jan 2001 20:23:07 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.17 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Re: An implementation of /dev/zero for DJGPP
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001225105646 DOT 18547E-100000 AT is> <3A489766 DOT 349B3C71 AT bigfoot DOT com> <9003-Tue26Dec2000184539+0200-eliz AT is DOT elta DOT co DOT il> <3A4B8307 DOT F4EF8D0 AT bigfoot DOT com> <3405-Sun31Dec2000092417+0200-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> So, the first time someone opens /dev/zero, dbg_fsext will be called
> and will register the fact that it was open.  The call to _open issued
> from dbg_fsext will then activate the /dev/zero FSEXT.  When the call
> to _open returns, dbg_fsext overwrites the value stored by
> __FSEXT_set_function by its own address.  From that moment on, the
> /dev/zero fsext will no longer be called when any operation on that
> handle is done.

Thanks for the explanation. If the debug FSEXT only allows the /dev/zero
FSEXT to handle the open operation, then the checks I had on the fd's
context data are OK, I think. IMHO anything that hooks the handling of
/dev/zero & /dev/full is asking for trouble.

If I were being really paranoid, I guess could add checks that the
function associated with the fd is the /dev/zero FSEXT function. If the
/dev/zero handler were not associated with the fd, then it would break and
pass through to the next handler.

> > So, I think the /dev/zero cannot cause trouble with the debug FSEXT.
> > (This is with /dev/zero being installed using __install_dev_zero(),
> > as discussed previously.)
> 
> If the debugger itself calls __install_dev_zero, its /dev/zero
> emulation will not work.
> 
> I'm not sure this is a grave limitation, but it at least should be
> documented somewhere.

I don't think this is a grave limitation either, since child programs will
be still be able to use /dev/zero, /dev/full.

Where do you think the best place to document this limitation is? In the
source code or in the library documentation?

Well, I think the FSEXT is complete now. I just need to write some fcntl()
and ioctl() tests. Actually, this leads to me to another question - why is
the section containing the FIONBIO ioctl #if 0'd out in sys/ioctl.h? Is
this to prevent some Unixy programs from thinking that we support, e.g.
terminal ioctls?

Bye, Rich =]

-- 
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]