Re: Regarding the ULTRIX and OSF1 compats

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

Le 16/03/2019 à 13:53, Robert Elz a écrit :
> 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).
> [... and the rest ...]

Ok. So you believe that dead wood should hold back all of the development
process? See below:

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

I believe you misread, 'iter' was not initialized, there is a goto earlier,
this could have been an exploitable vulnerability. As I said, this is one
example among others.

And yes, this bug was introduced because the API was being replaced, and yes,
the person who committed this code likely did all he could to make sure no
bug was introduced, and yes, he did still add a bug because a certain number
of these compat layers are dead wood that can't be tested, not even by those
who claim they are so important.

In fact, all of your "rules" were respected, yet the bug still inevitably
came in. Why is that? This is what happens with dead wood, you just don't
want to face it. The reality is that very, very, very few (if any) people
care about our esoteric compat layers; no one is testing them, no one is
actively using them, no one even ever reads their code.

And I'm not even speaking for myself, you just have to see the answers to
"does anyone use compat_xxx". You can even try as hard as I did, with
COMPAT_SVR4, ask on several different mailing lists, repeatedly, over and
over. No one ever answers.

> 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 ?

If UVM was of questionable utility, yes, absolutely. Except it isn't. The
compat layers we've talked about (SVR4, IBCS2, now OSF1) _are_ of questionable
utility, as discussed.

I stated my point clearly and logically, about why certain things have
legitimate reasons to go away, regardless of whether they are compat layers,
or drivers, or something else. Rather than giving clear, logical counter
arguments, you are just repeating "XXX is YYY years old, remove it".

You are going to have to provide better arguments I'm afraid, because you're
not going to convince _*anyone*_ with that.