Re: Regarding the ULTRIX and OSF1 compats

[Maxime Villard <max%m00nbsd.net@localhost>]

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'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.

If the situation was as you described, I wouldn't mind. But to me, the old
unmaintained code is a significant barrier to many improvements; so when the
code in question has a questionable utility or is even known to be broken,
there need to be talks about removing it.

Hence my emails.

Also, this thread seems to have diverted towards "interoperability", but I
don't see what is the debate here. Dead wood is dead wood, regardless of
whether it is a compat layer, or a driver, or a network protocol, or even a
complete architecture (as has been done in the past already). We can disagree
on the deadness of it, but I don't see the debate about interoperability.

And as I said, I believe it is futile to talk about interoperability in the
case of broken features (eg SVR4); the thing was completely broken, so it
didn't make NetBSD more interoperable. Maybe the only thing it did was making
NetBSD more buggy.