Le 20/11/2018 à 16:18, Greg Troxel a écrit :
I used to use it, and may again. So I'd like to see it stay, partly because I think it's good to keep NetBS relevant in the fileystem research world. I am expecting to see new upstream activity.
The problem is that CODA is not relevant in this world either... Developed since 1987, hasn't gone very far, seems to have been dropped by everybody except us and Linux. There appears to be some activity in the Linux source from time to time, but nothing really significant at a first glance. Our code, on the other side, hasn't moved at all. The research world of today is much more around ZFS and HammerFS, neither of which we support correctly. Keeping dead wood of the previous century for the sake of "research" is really bad IMHO. Filesystems (just like network drivers) consume APIs, and now we find ourselves making blind changes without even testing, because there are just so many things to test. So here we are, someone did try to mount a CODA filesystem, and figured out that there are obvious KASSERTs that are firing, because the vnode locking was revamped but not tested there... We have the CODA code in the source tree, but we don't maintain it, and no one else does either. I think keeping dead wood like that doesn't serve any particular purpose, except making life harder for people that want to revamp stuff. But I'll leave it there.
But, I think it makes sense to remove it from GENERIC, and perhaps have whatever don't-autoload treatment, so that people only get it if they explicitly ask for it. That way it should not bother others.
I agree that we should disable it from GENERIC. It is as experimental as several other FSes that are disabled, so it does make sense.
