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 dholl...@netbsd.org
