Re: unhooking lfs from ufs

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Feb 08, 2010 at 03:37:37AM +0000, Eduardo Horvath wrote:
 > > Anyhow, it seems to me that isolating it from changes to ffs is likely
 > > to result in less breakage over time, not more. Can you expand on your
 > > reasoning some?
 > 
 > The most significant parts that are shared are the directory ops and the 
 > read/write routeines.
 > 
 > The directory ops are essentially FFS code with an LFS wrapper around it.  
 > Right now any ffs bugfixes for those used directly by LFS.

However, several of those wrappers are truly vile, some of them AFAICT
compromise LFS's transactional update model, and they all require
stretching the LFS code to fit a paradigm that it isn't suited to.
Plus some of that code suffers pretty badly from having been written
in 1983.

There aren't that many changes to the ufs code anyway. Those changes
that do appear are easy to bring across to portions of the copied ufs
code that haven't been altered much; once significant portions have
been, fixes for those portions are much more likely to be flowing the
other way. (Why? Because aggressive rototilling has this way of
exposing bugs.)

 > If we were to separate them out then every time someone fixes a problem 
 > with FFS, the same changes would be required to be made for LFS.  

I've been doing this in my lfs tree since July (when I prepared most of
the changes) and it's taken me negligible amounts of time.

 > Historically this has not happened.  When you look at UVM or UBC 
 > integration, there were long periods of time when LFS was unusable because 
 > that filesystem has been considered of secondary importance.  

Right, and we're in one of those periods, and the goal is to get out
of it and stay out of it...

 > I would love to hear someone allay my fears, but I think segregating the 
 > LFS code from the FFS code will accelerate the bitrot and the final result 
 > will be removal of the LFS code.

Well. lfs is currently pretty broken and without a substantial
rototill it's going to stay broken. And if it stays broken, it's
certainly going to end up removed. Certain people have already been
agitating to remove it.

It seems to me that unhooking lfs from ufs is the necessary first step
towards any substantial overhaul of lfs. This is why I'm proposing it.

There are some people who would like this unhook done so that lfs
stops complicating ufs; they will doubtless be happy to ignore lfs
afterwards, but my goal is to make it work.

-- 
David A. Holland
dholland%netbsd.org@localhost