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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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