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.
