Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3A64BFB3.5FAEC72B@phekda.freeserve.co.uk>
Date:	Tue, 16 Jan 2001 21:40:03 +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 AT delorie DOT com
Subject:	Re: /dev/zero & /dev/full FSEXTs
References:	<E14EtVu-0000G9-00 AT phekda DOT freeserve DOT co DOT uk> <8632-Sat06Jan2001203659+0200-eliz AT is DOT elta DOT co DOT il> <3A63764C DOT 2CE7F394 AT phekda DOT freeserve DOT co DOT uk> <200101152231 DOT RAA00825 AT envy DOT delorie DOT com>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

DJ Delorie wrote:
> > Would an FSEXT hook for setmode() be useful?
> 
> Why?  Isn't the bin/text processing done in the layer above fsext?

I don't know enough about the inner workings of the I/O routines to answer
that. I was just posing the question from an ideological point of view.

> > What do you think the behaviour for SEEK_CUR and SEEK_END should be?
> 
> It's not a real file, so you can't seek in it.  IMHO it should return
> a "not a file" error.

For /dev/zero this is probably OK.

The full(4) man page on Linux says that "[s]eeks on /dev/full will always
succeed", so I'm not sure we can do that for /dev/full. One solution is to
pretend that /dev/full is a 2GB file (i.e. maximum off_t) and store the
current offset. Then SEEK_* could be handled better than the current code.
OTOH if you don't think this is a good idea, then I will make it return
the error, as you suggest.

Does anyone have an idea what happens on other systems?

Bye, Rich =]

-- 
Richard Dawe <richdawe AT bigfoot DOT com> http://www.bigfoot.com/~richdawe/ 

"The soul is the mirror of an indestructible universe."
--- Gottfried W. Leibniz

- Raw text -