Re: unhooking lfs from ufs

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Sun, 7 Feb 2010, David Holland 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.  

The read/write routines also share about 80% of the code.  I suppose there 
is a better case for separating these out if it makes code maintenance 
easier.

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.  
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.  

LFS has a rather small user base since it's historically been considered 
experimental and most machines can't boot from it.  Few people use it and 
fewer still work on 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.

Eduardo