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" From: Randy Maas 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 Content-Type: text/plain; charset="us-ascii" Precedence: bulk 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