[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: unhooking lfs from ufs
Eduardo Horvath wrote:
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
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.
So, the fact that the code was shared did indeed *not* make FFS fixes
also flow over into LFS? (I assume that FFS was fixed for those things
in short order.)
That would, in my eyes, mean that this argument isn't valid.
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.
Indeed. I tried LFS a few times many years ago, but had some problems
with it, along with the "experimenal" status of it, which made me stop
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.
I can't alleviate your fears, however, it appears to me that the
assumption that LFS benefits from sharing code with FFS is wrong, or
atleast exaggerated. Looking at how the LFS code have had problems for
extended periods, even with shared code with FFS suggests that LFS have
not really gained much from that sharing.
Having the code split, and then possibly getting it leaner and cleaner,
looks like a potential gain atleast.
Main Index |
Thread Index |