Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!agate.berkeley.edu!cgd
From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: Re: 4.4BSD
Date: 12 Jan 94 21:17:18
Organization: Kernel Hackers 'r' Us
Lines: 30
Message-ID: <CGD.94Jan12211718@eden.CS.Berkeley.EDU>
References: <2gvt5c$dr0@senator-bedfellow.MIT.EDU> <CGD.94Jan11204734@eden.cs.berkeley.edu>
<2h2k6n$6in@panix.com>
NNTP-Posting-Host: eden.cs.berkeley.edu
In-reply-to: tls@panix.com's message of 12 Jan 1994 23:54:47 -0500
In article <2h2k6n$6in@panix.com> tls@panix.com (Thor Lancelot Simon) writes:
>Still can't understand why nobody can have the VFS module implementation of
>LFS to hack at. LFS is clearly a product of the Sprite project, and Berkeley
>has no problem distributing Sprite -- yes, I know LFS won't run without major
>buffer-cache hacking -- but why oughtn't we be able to start such stuff?
"clear as solid stone"?
The idea that produced LFS came from the sprite project, that much is
true. However, the implementation is different, BSD-ish. I can't say
for sure, but i'd bet that what routines could be were cloned off
of the corresponding UFS routines. In any case, 4.4BSD LFS is
decidedly *NOT* the Sprite code.
Also, even if you got 4.4's LFS, you'd still be SOL, because of the
way CSRG split up the file system code. the size of the lfs code is
about the same as the size of the "generic ufs" code (i.e. the "UNIX FS"
semantics-handling goop, which is common to the FFS and LFS. You'd have
about half of the code that you needed for a functional file system.
Sure, the the "generic ufs" code could probably be boiled out of net/2's,
but it wouldn't be easy at all...
cgd
--
chris g. demetriou cgd@cs.berkeley.edu
smarter than your average clam.