Recent Features
| |||||||||||||
KS2007: The distributor panelKS2007: The distributor panelPosted Sep 7, 2007 12:50 UTC (Fri) by hmh (subscriber, #3838)In reply to: KS2007: The distributor panel by mgb Parent article: KS2007: The distributor panel
When you factor in bad design bugs that made it into mainline and we need a way to be able to fix them, you will see it is not just a matter of a "playground" for developers. The playground is probably where people are when they send to mainline badly designed APIs and ABIs.
Now, regressions and ABI breakage to *userspace* are a major pain, but one we can't just do without completely. Userspace ABI changes need to happen sometimes, or we will end up as another Microsoft Windows, loaded with past mistakes and design errors.
There are ways to lessen, or at least share that pain better, though. Such ABI breaks should at least be strongly documented, and tested for. Yes, break it. But know that you are breaking it, exactly how you are breaking it, and document it explicitly in a easy-to-find, standard place.
(Log in to post comments)
KS2007: The distributor panel Posted Sep 7, 2007 18:23 UTC (Fri) by mrshiny (subscriber, #4266) [Link] The thing is, ABI changes don't need to be forbidden, they should just happen less frequently. With the modern 2.6 kernel, EVERY SINGLE RELEASE can potentially contain ABI changes. At least in the 2.0/2.2/2.4 days there were more guarantees of stability for the lifetime of the kernel. This could be enough to get drivers out the door and into customer hands and simultaneously into the tree.
As another article mentioned, even if a vendor gets their driver into the tree it might be months or years before this driver gets into customer hands. In the meantime, for anyone currently running Linux, the driver may as well not exist because basically nobody runs kernel.org kernels. The only option is if the vendor backports the driver to popular kernels, of which there are dozens.
People keep comparing ABI stability to Windows, but they forget some things: 1. Windows isn't necessarily ABI-compatible from release to release, but it is supposed to be for the lifetime of one release including service packs.
KS2007: The distributor panel Posted Sep 7, 2007 19:54 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Despite GregKH's arguments to the contrary I still think the kernel devs have made a mistake in abandoning API/ABI stability. We don't need to keep bad APIs or bugs around forever, but _some_ stability would go a long way. Pray tell, how much is "some"? Whatever you decide, some parties will be unhappy...
KS2007: The distributor panel Posted Sep 7, 2007 20:42 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] quote:The thing is, ABI changes don't need to be forbidden, they should just happen less frequently. With the modern 2.6 kernel, EVERY SINGLE RELEASE can potentially contain ABI changes. At least in the 2.0/2.2/2.4 days there were more guarantees of stability for the lifetime of the kernel. This could be enough to get drivers out the door and into customer hands and simultaneously into the tree.
did you actually use the 2.0/2.2/2.4 kernels that you are talking about? I did (I've been using Linux in production environments since around 2.0.30 and on my own systems prior to 1.0) and there was no more ABI stability between different releases then there is with the 2.6 kernel, every release changed something.
now the 2.6 development is much faster, so the amount of changes that took place in 2.0 in a year are taking place in a few months in 2.6, but they are spread across a larger code base as well.
and you are ignoring the fact that in the 1.2/2.0/2.2/2.4 days the kernels from RedHat, SuSE, and Linus were frequently not compatible with each other. you had to change userspace noticably when moving from one kernel series to another (the NPTL stuff is RedHat is the biggest example, but far from the only one).
the other big problem from the 1.2/2.0/2.2/2.4 days was the fact that you frequently couldn't run a stable kernel on your hardware, the driver (or a _working_ driver) was commonly only available in the development series (and developers, including leading ones like Alan Cox would tell you to run the development kernel rather then the stable kernel). I ended up deploying a 2.1.166 kernel on a production box that I mailed across the country to the data center because I needed the 3com NIC driver to work.
I'll take the current rate of change over these sorts of problems any day.
|
|||||||||||||