On Sat, Mar 16, 2019 at 12:36:17PM +0100, Maxime Villard wrote: > Le 16/03/2019 ? 12:17, Robert Elz a ?crit : > > If there are bug reports that are not being attended to (open PRs), > > that's different. Otherwise unmaintained code is simply code that > > doesn't need changes (which for emulation of ancient systems is not > > a huge surprise - those systems aren't changing any more, if the > > emulation is adequate for its purpose - which does not mean it has > > to be complete - then there is no reason for it to ever change again.) > > I understand this point. But to me it is deeply wrong: the compat > layers use system APIs, and these APIs do change regularly. You > can't change the VFS locking without changing the implementations > of each compat layer; yet indeed the emulated systems aren't > changing anymore.
I haven't read the whole thread yet so I probably shouldn't jump in until I have, but since this touches specifically on me: We (meaning I, but not just me) can make and have made sweeping VFS changes and the existence of random compat layers and their "special" notions of filesystem ops has never been even a minor obstacle. You may not use this as a justification for deleting _any_ compat layer, never mind one that anybody's actually using. > I've already given this example (and it is one among many others): > > https://mail-index.netbsd.org/source-changes/2017/12/03/msg090179.html > > From my point of view (of someone who did want to change the mbuf API for > instance, and who realized it was just impossible given the ton of dead wood > that uses it), in these cases, we are forced to take the time to make blind > changes which may be wrong. It costs us the effort, and makes us add bugs. The mbuf interface is a mess, but it's not as big of a mess as the namei interface was. When such things are fixed properly, the changes needed are mechanical, easily audited, and easily fixed later if you slip up. So I do not agree with this reasoning either. -- David A. Holland dholl...@netbsd.org
