Le 09/03/2019 à 18:58, Jason Thorpe a écrit :
On Mar 9, 2019, at 8:22 AM, Maxime Villard <max%m00nbsd.net@localhost> wrote: New thread, CC'ed to port-pmax@ and port-alpha@, in the continuity of: https://mail-index.netbsd.org/tech-kern/2019/03/09/msg024754.html Basically, there were talks about retiring COMPAT_ULTRIX and COMPAT_OSF1, because they are of questionable utility, in addition to being clear dead wood; as I said, limited use case, no maintenance done in these areas, inability to test changes, and the list goes on. So, does anyone have anything to say about that?I'm completely in favor of removing COMPAT_OSF1 ... it was useful back in the early days of the Alpha port because the native toolchain was shaky (and there was the whole ECOFF -> ELF transition). But it was never good enough to run many real applications because it doesn't implement any of the Mach traps. To fix it for real, we'd have to implement a ton of infrastructure (including MiG), and I don't think anyone wants that horror show.
Alright
COMPAT_ULTRIX is a much thinner shim on top of of COMPAT_43, similar to COMPAT_SUNOS, which we keep around for other reasons, and so I think the wood is a little less obviously-dead. Its biggest wart is having to exec ECOFF binaries. I don't know if anyone is actively using it at this point, though.
Well, as far as I can tell no one has been maintaining it for quite some time now, and it has now reached the point where people make blind changes without being able to test; and the code is deprecating all along. Typically like this: https://mail-index.netbsd.org/source-changes/2017/12/03/msg090179.html It seems that, slowly, it will reach the final stage: being completely broken, like SVR4. When the feature in question has a questionable utility, I'm even more in favor of cutting the wood right away...