From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] hardware support for the fs kernel
Message-ID: <20030313095950.S24866@cackle.proxima.alt.za>
References: <20030312122847.I24866@cackle.proxima.alt.za> <3d6f979f175b54f3f6c960e7acb3c71a@plan9.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <3d6f979f175b54f3f6c960e7acb3c71a@plan9.bell-labs.com>; from Russ Cox on Wed, Mar 12, 2003 at 12:15:41PM -0500
Date: Thu, 13 Mar 2003 09:59:51 +0200
Topicbox-Message-UUID: 7f4271b2-eacb-11e9-9e20-41e7f4b1d025

On Wed, Mar 12, 2003 at 12:15:41PM -0500, Russ Cox wrote:
> 
> > Fossil/Venti won't serve my 2ed and 3ed museums :-)  I like the 3.5ed
> > server, pity longnames are incompatible with the disk structures.
> > Maybe my question should have used "obsolescent" rather than
> > "obsolete".
> 
> It would be utterly trivial -- maybe 100 lines of code -- to
> write a srvold9p to do the translation.  Kfs and u9fs have
> this built into them.  We dropped it from fossil because it
> is time to move on, but it would be easy to make it a separate
> user program.  There's literally no state needed.  There's
> an easy embedding from old to new requests and then new to 
> old responses.
> 
Yes, that's an excellent idea and I will look into it.  I would
certainly consider running a single fossil file server for all
conceivable purposes.  Right now, I'm sticking to the 3.5ed file
server because I have too much on my plate and too little is actually
getting done as a result.

Unless my reading of the Fossil documentation deceives me, fossil
gets its own namespace to serve, in which case it could also
assimilate duplicates into the namespace (the maps, fonts, astronomical
data) before serving the single copy to different requesters.  That
would be quite convenient.  Fortunately, one doesn't need to
continually update these information libraries, but consolidating
them into a single image would certainly be beneficial.

Another benefit would be the ability to serve arbitrary media: the
old fileserver, in my particular case, could not serve the contents
of the two CD-ROM changers, fossil will be better geared to do so.
I never considered that I would be wooed over by the new file server
being just another application, I always believed that it ought to
stand alone.  I guess one never stops learning :-)

> (Our current program called srvold9p is really mountold9p.)
> 
Good point, wouldn't be hard to rename it "mntold9p", although
renaming "srv" to "mnt" is right out of the question.  I find having
to resort to "-u none" all the time (am I misunderstanding the
documentation?) a little restrictive and irritating.  It probably
ought to have been the default.

++L