Message-Id:	<3.0.1.32.19971126114818.007eb680@yacker.xiotech.com>
Date:	Wed, 26 Nov 1997 11:48:18 -0600
To:	"Markus F.X.J. Oberhumer" <k3040e4 AT wildsau DOT idv-edu DOT uni-linz DOT ac DOT at>
From:	Randy Maas <randym AT acm DOT org>
Subject:	Re: proposed fsext changes
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<199711261656.RAA25208@wildsau.idv.uni-linz.ac.at>
References:	<3 DOT 0 DOT 1 DOT 32 DOT 19971125104044 DOT 007e34f0 AT yacker DOT xiotech DOT com>
Mime-Version:	1.0

At 05:56 PM 11/26/97 +0100, Markus F.X.J. Oberhumer wrote:
>Could you please explain me your motivation behind this large
>amount of fsext changes ?
>
>If you want to write a pipe emulator or a RAM disk, fine, but
>why blow up the standard library with lots of callbacks to your 
>application instead of just going the other way round ?

Partly because I think the fsext is an excellent way of an add-on library
to extend djgpp.  To a certain degree, djgpp can be made more useful
(transparent to a well written application) without recompiling djgpp's
libc.  

I used the RAM disk, well, because I wanted to see if it would help speed
up temporary file usage.   Maybe that is not typical -- the only other one
of its type (and is much more interesting) is the ext2fs library.   If
anyone knows what is (or should be?) a typical fsext, please let me know.

Here is a break down of what motivated most of the changes I have proposed:

Type of ext	libc modification	Notes
pipe		dup2 (for stdio), lseek	pipe is probably only going to be used by
unix-style programs...
/dev/ttyS	dup2			the most commonly request fsext I've seen.  Mostly for
portablity between linux and djgpp
symlink		unlink,link		A symlink ala win95 style shortcuts 
ram-disk,ext2fs	link, unlink, lseek

well, that's my .1 cent worth. 
Randy

- Raw text -