[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: unhooking lfs from ufs
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
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
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.
Main Index |
Thread Index |