>> 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.
Ideally, yes. But I doubt that _any_ of the people who would make such changes can test all the compat layers; I'm fairly sure most can't. Consider thorpej's mail of 2019-03-05 10:54:40 (<56cbb3c3-95fe-4a55-8839-329e0d9f1...@me.com>). If I'm reading right, he tested one arch and one variant of another (arm) on real hardware, four arches and two other variants of arm under emulation, had trouble with emulating four arches, wrote of platforms he needs help with "due to lack of good emulation environments" for four more, and listed four others "in the WTF category". And that was exemplary - I doubt most of the new guard would have done that much, since most of them are not, what was the phrase, "industrially relevant". And, if I'm reading right, that was stuff that didn't require foreign software to test. But back in the days when NetBSD as an organization still cared about the small/slow ports, I often enough saw people ask for testers to help test MI changes on various ports, only to get, as far as I could see, no response at all. The only options under such circumstances are to make the changes blind and sometimes break things, or to fail to progress. > (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.) That borders on meaningless. If Ultrix never ran on SPARC or x86_64 (which was the case AFAIK), what would it even mean to be compatible with it? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
