5 ms·

No, your anecdotes do not constitute facts or objectivity. More importantly, I'm not the person you would have to convince, and the people who would need

No, your anecdotes do not constitute facts or objectivity. More importantly, I'm not the person you would have to convince, and the people who would need to be convinced consider this argument over and done with long ago. Then why are you still arguing it? Why are your anecdotes somehow superior to mine (if you want to call an entire mainstream market "anecdotal" evidence)? By accumulating a massive amount of cruft that they can never remove. Yes, it's possible; it's also possible to run the old kernel in an emulation layer to run older drivers, but that doesn't make it a good idea. (Though that'd probably still be a better idea than attempting to support the old in-kernel APIs in a newer kernel.) No, and no. As a kernel developer (my day job) I can assure you that is not the case. And note I never said that you have to maintain ABI/API compatibility forever. Even operating systems with stable API/ABIs do change them from major release to major release. The point is, the Linux kernel could successfully adopt a stable ABI/API without accumulating all of the "massive cruft" you claim is impossible to avoid and make lives better for their users. At the very least, providing an ABI/API they guarantee to be stable for some period of time instead of breaking things almost every point release. And incidentally, if you need kernel ABI stability, you can also go run RHEL, which backports changes from newer kernels while maintaining in kernel ABI stability for out-of-tree drivers, within a given major release. So for the support lifetime of that RHEL release, you can count on ABI stability. So in other words, there's a genuine need for a stable API/ABI and RedHat supports it, but you still think it's stupid and useless to have and there's clearly no need for Linux to do it, except RedHat has proven there is a market for it. Hmmm.... And, in practice, a shockingly successful one. There's very little mainstream hardware left that the kernel doesn't have in-tree support for. (No, that's not an invitation to enumerate the remaining exceptions.) And even for a fair bit of nVidia hardware there's the reverse-engineered nouveau driver, which is good enough for desktop environments and light gaming on the hardware it supports "Pay no attention to the exceptions; it's a complete success!" The exceptions are proof that it's not a complete success and yes, quite frankly, some hardware that is not widespread enough or is special to a given organisation doesn't belong in the Linux mainstream kernel. What would be the point of "accumulating all that cruft" after all... However, for a production-quality Linux system, it makes more sense to select hardware with in-tree drivers. Right, because all of those Linux systems at DreamWorks and other places with nVidia cards in them aren't "production-quality"; oh wait... And how many of those various crashes and other problems reported with nVidia systems are due to the rapid changes in the Linux kernel instead of the driver itself? You could argue it's hard to say without source to the nVidia driver, but that seems like a tautology at best. It's fine that we disagree, but your assertions thus far are easily contradicted by the entire mainstream market (nevermind your own RedHat example) so sound kind of silly.

JoshTriplett 12y ago
> Then why are you still arguing it? Why are your anecdotes somehow superior to mine (if you want to call an entire mainstream market "anecdotal" evidence)? I'm giving the stated reasons for why Linux intentionally has no stable in-kernel ABI, and what some of the downsides of having one are. That's not an anecdote, that's a description of the stated design philosophy (see also https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt https://www.kernel.org/doc/Documentation/stable_api_nonsense... ). You gave exclusively upsides to having a stable ABI, as though it was an obvious design failing of the Linux kernel, rather than a tradeoff. To be clear: I absolutely agree that it's possible to provide driver interfaces that don't change; as you said, systems like Windows provide evidence of that. But that doesn't come without a cost. But I'd be happy to be proven wrong; just point to the source code of one of the kernels you mentioned where they implement a stable kernel ABI without any accumulated cruft...oh, wait. ;) > And note I never said that you have to maintain ABI/API compatibility forever. Even operating systems with stable API/ABIs do change them from major release to major release. You gave no indication that you ever considered it acceptable to break ABI. I'm certainly in agreement that ABI shouldn't be broken gratuitously for its own sake; however, it shouldn't be necessary when making a change to the kernel to think about whether out-of-tree drivers (that nobody can see the code of) depend on the behavior of a particular function call, or the layout of a data structure, or the context a given function can be called in. > So in other words, there's a genuine need for a stable API/ABI and RedHat supports it For RedHat paying customers who intentionally want to run the same software for 5+ years at a time and avoid any changes, sure. It makes no sense for the upstream Linux kernel to give those same guarantees while doing active development. 5 years ago was roughly 2.6.36. That's 5 years and ~24 kernel releases where not a single field can be added or removed from a data structure, no argument can be added or removed for an existing function, and semantics like "what lock do you need to hold to call this function" cannot change. (There's a lot more to ABI than just function calls and data structures, particularly when you're talking about a C ABI between privileged code running in the same address space.) Maintaining compatibility like that would completely hamstring day-to-day development. If you have that kind of compatibility requirement for a kernel, and that kernel remains under active development (rather than being declared done and untouchable, which is another option used for some embedded systems or microkernels), you'd need to heavily rework your architecture and development processes to insulate the actively-developed kernel from the drivers, generally by introducing something like a HAL, so that the kernel can change as long as it exposes a compatible HAL. Then you get into issues like HAL versioning, including potentially supporting multiple versions at once, interactions between drivers and interfaces provided by one driver to another, and so on. All for the sake of offering better support for drivers that refuse to submit their code to the upstream Linux kernel. So yeah, it's possible to build a kernel that provides interfaces that drivers can rely on across many versions. Not without a cost, though.

JoshTriplett 12y ago

> Then why are you still arguing it? Why are your anecdotes somehow superior to mine (if you want to call an entire mainstream market "anecdotal" evidence)? I'm giving the stated reasons for why Linux intentionally has no stable in-kernel ABI, and what some of the downsides of having one are. That's not an anecdote, that's a description of the stated design philosophy (see also https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt https://www.kernel.org/doc/Documentation/stable_api_nonsense... ). You gave exclusively upsides to having a stable ABI, as though it was an obvious design failing of the Linux kernel, rather than a tradeoff. To be clear: I absolutely agree that it's possible to provide driver interfaces that don't change; as you said, systems like Windows provide evidence of that. But that doesn't come without a cost. But I'd be happy to be proven wrong; just point to the source code of one of the kernels you mentioned where they implement a stable kernel ABI without any accumulated cruft...oh, wait. ;) > And note I never said that you have to maintain ABI/API compatibility forever. Even operating systems with stable API/ABIs do change them from major release to major release. You gave no indication that you ever considered it acceptable to break ABI. I'm certainly in agreement that ABI shouldn't be broken gratuitously for its own sake; however, it shouldn't be necessary when making a change to the kernel to think about whether out-of-tree drivers (that nobody can see the code of) depend on the behavior of a particular function call, or the layout of a data structure, or the context a given function can be called in. > So in other words, there's a genuine need for a stable API/ABI and RedHat supports it For RedHat paying customers who intentionally want to run the same software for 5+ years at a time and avoid any changes, sure. It makes no sense for the upstream Linux kernel to give those same guarantees while doing active development. 5 years ago was roughly 2.6.36. That's 5 years and ~24 kernel releases where not a single field can be added or removed from a data structure, no argument can be added or removed for an existing function, and semantics like "what lock do you need to hold to call this function" cannot change. (There's a lot more to ABI than just function calls and data structures, particularly when you're talking about a C ABI between privileged code running in the same address space.) Maintaining compatibility like that would completely hamstring day-to-day development. If you have that kind of compatibility requirement for a kernel, and that kernel remains under active development (rather than being declared done and untouchable, which is another option used for some embedded systems or microkernels), you'd need to heavily rework your architecture and development processes to insulate the actively-developed kernel from the drivers, generally by introducing something like a HAL, so that the kernel can change as long as it exposes a compatible HAL. Then you get into issues like HAL versioning, including potentially supporting multiple versions at once, interactions between drivers and interfaces provided by one driver to another, and so on. All for the sake of offering better support for drivers that refuse to submit their code to the upstream Linux kernel. So yeah, it's possible to build a kernel that provides interfaces that drivers can rely on across many versions. Not without a cost, though.