Date: Sat, 16 Mar 2019 12:36:17 +0100
From: Maxime Villard <m...@m00nbsd.net>
Message-ID: <9717b459-eb3c-c899-1dd5-019f1c6e8...@m00nbsd.net>
| I understand this point. But to me it is deeply wrong: the compat layers use
| system APIs, and these APIs do change regularly.
Whoever is changing them should be fixing all the users of those APIs,
including the ones in the compat code. Consider all the work PaulG
did as part of the kenel module changes recently -- that's an example of
how it should be done. Simply deciding an API should alter, and changing
the few places that you care about is not good enough. (generic "you" not
personal there).
| You can't change the VFSlocking without changing the implementations
| of each compat layer;
Sure.
| yet indeed the emulated systems aren't changing anymore.
Then the VFSlocking changes should be backed out until the users of the
API are all being updated. I know it is not always easy to test mods
like this, but we can at least make a best effort attempt to update code
to the new model (all the code) and then if there's a problem, fix it when
reported.
| 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
That's not an example of anything useful. There was a bug. It was
(apparently) reported. It was fixed (you fixed it!)
That it hadn't been reported for a long time merely meant that no-one
had noticed it. In that case, that's not surprising, the bug was when
copyout() failed, which in practice is a very rare event - as it normally
requires bugs (and often really dumb bugs) in the application as well.
That's why I said we need to have reported bugs that are not being fixed.
Not just bugs it is possible to find when looking hard enough.
A similar example would be the mlock(addr, 0) bug that was fixed the
other day. That had also been there for ages (perhaps since UVM was
added). Should the existence of that bug for such a long time be a
justification for removing UVM ?
The same for the shmctl(SHM_LOCK)/munlockall() problem that syzkaller
found (and Kamil told me about) which is not yet fixed. That's been
there just as long (or something). Maybe we should remove shm ?
(That one I personally wouldn't oppose ... but I doubt it would be a
good idea.)
| 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),
Dead wood from your point of view. And yes, sometimes it simply is
too hard to make changes, however nice it would seem tp be.
And:
| 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.
yes, that can happen - any change takes efrfort and can result in adding
bugs. If you're not willing to put in the work, or not willing to fix any
bugs that are created, when they are reported, then you shouldn't be making
changes.
What we probably need for the compat code is a method to switch the
emulation for a thread of a process (dynamically) - that way we could
write new tests for things that are being chnaged, without relying on
code that actually comes from the emulated system (or even is necessarily
from an architecture that would ever normally want that compat option -
so we could include COMPAT_ULTRIX on a sparc or x86_64 for testing purposes.)
| there need to be talks about removing it.
|
| Hence my emails.
All that is fine - as long as you understand that the talk will not
necessarily result in anything being removed. No matter how sure you
are that that is what would be best.
| We can disagree
| on the deadness of it, but I don't see the debate about interoperability.
Maybe some poor wording choices - I think the point is more functionality.
We want to keep the ability to run old binaries, from old NetBSD, and from
other systems. Whatever you want to call that, that's what is wanted.
| And as I said, I believe it is futile to talk about interoperability in the
| case of broken features (eg SVR4);
I am not going to discuss details of things I don't know enough about
to have a reasoned opinion about - which is why I made no observations
about COMPAT_ULTRIX or COMPAT_OSF1 until we got into the "supporting that
stuff isn't relevant any more" issue.
kre
