| |||||||||||||
|
| |||||||||||||
Quote of the weekQuote of the weekPosted Dec 16, 2004 4:58 UTC (Thu) by mrshiny (subscriber, #4266)In reply to: Quote of the week by elanthis Parent article: Quote of the week
Exactly. I'm all for letting the kernel guys break things every major release, but since we don't have those anymore, I guess binary compatibility is just something nobody on the kernel team cares about. So if you have some hardware that has a binary module that doesn't work on the latest kernel, I guess you're out of luck with regards to security fixes or whatever.
(Log in to post comments)
Quote of the week Posted Dec 16, 2004 14:37 UTC (Thu) by Duncan (guest, #6647) [Link] The idea is to encourage you to buy hardware with open source support(read that as manufacturers releasing enough specs for open source folks to decently support it) next time. If enough people are so encouraged, it'll drive demand for such hardware, and someone will fill it, even if the current big players refuse to do so. It's not the kernel folks who chose to keep their stuff proprietary so it couldn't be supported and updated along with the rest of the kernel tree. I'm running an ATI 9200se graphics card. Why? Because it's about the last card ATI produced that they made the specs available for, thus, that has decent open source support. NVidia never has, and ATI got tired of the old XFree folks dragging their feet so quit doing so as well. Perhaps they'll be persuaded to change their mind, with a much more responsive Xorg, which has vastly improved the open source Radeon drivers over the last year. That 9200 might not be the fastest on the block, but it works, and I'm not supporting products where the manufacturer has chosen not to support open source by even making the hardware specs available. Duncan
Quote of the week Posted Dec 16, 2004 15:09 UTC (Thu) by mrshiny (subscriber, #4266) [Link] I understand the need to buy hardware that is supported with open-source drivers. But what if you can't get hardware that is supported? My need to use the computer outweighs my need to use open-source drivers. This is especially true of many businesses which rely on custom solutions. They can't just stop using a piece of hardware because it's not supported; they are locked in. Sometimes there is no alternative anyway, open or not.
For example, take video cards. You mentioned that you use an older model of video card because it's the last well-supported ATI card. Using an older card won't help you play Doom3; you need a newer card that has better features. Your choices are: buy ATI or nVidia, or don't play Doom3. The applications (or games) drive the computer, not political ideology. A computer doesn't exist in a vacuum.
Anyway, your comment about the relationship between ATI and XFree86 seems to prove my point: commercial companies won't support Linux/Free software if they have to keep working around the games and politics of the developers.
Quote of the week Posted Dec 16, 2004 15:37 UTC (Thu) by wookey (subscriber, #5501) [Link] You rather dimiss the option 'don't play Doom3', but I think that is the correct choice in the circumstances and the one I am currently choosing. I agree that sometimes it is not practical to avoid non-free drivers, but the advantages of doing so are huge, and personally I don't mind at all if the kernel developers build those advantages even higher.
We design hardware and one of the most important criteria is 'are there specs or a free driver for it' - if not it doesn't get designed in. I'm sure there are loads of companies making this same choice, and I'm pretty confident that free drivers will win in the end (modulo life being made impossible by bad patent law).
Quote of the week Posted Dec 16, 2004 16:22 UTC (Thu) by mrshiny (subscriber, #4266) [Link] Well, I used Doom3 as an example, since it is the choice I am making soon when I upgrade my hardware. However, the analogy stands, for people who have legitimate needs that are not met by opensource drivers. Don't get me wrong: I wish NVidia had better opensource support. But even if all I used linux for was 2D, the nv driver that ships with X.org is much slower than the NVidia driver. Frankly there's no choice when it comes to video cards for me: NVidia or ATI. If there were a video card maker who had cards that had nearly the 3d quality of these two, but worked with a 100% open-source driver, I'd jump on that in a second. But the reality is that there is not, and my "need" is to play Doom3, so I am locked into a proprietary driver.
Some people need other particular hardware to get their job done, and there is no chance to replace it with something better. As a hardware maker, you can make choices about the hardware and its openness, but as a hardware user I have to buy the hardware that does the job, or do without. For many people, doing without isn't an option.
Quote of the week Posted Jan 3, 2005 16:59 UTC (Mon) by atrius (guest, #26979) [Link] No, what it really ends up causing is people asking someone like me if a given piece of hardware works in Linux and I am forced to answer with either a no, or yes, but only if you're using distro A, with kernel B, with sub-patch C. Especially in the category of video cards. Yes, there are open source drivers for most/all video cards. Most of them just suck or only support the bare minimum of the feature set. Most often without 3D support at all, or at least not all of the features. Yeah, that sounds good.
Quote of the week Posted Dec 16, 2004 15:04 UTC (Thu) by elanthis (subscriber, #6227) [Link] This isn't about binary modules!
It's about _all_ modules. Even GPL modules that are in-tree. If 2.6.10 has new module FooWhiz for some new harder, the only way for any user to use that hardware is to upgrade to 2.6.10. Distros are not going to release upgraded kernels, *especially* with the new kenerl development "model" (if you can call it a model), because new point releases aren't just bug fixes and driver additions, they're practically all new kernels.
So the only way for a user to get a new, upgrade perfectly GPL module is to upgrade their entire kernel. Manually.
Quote of the week Posted Dec 16, 2004 16:18 UTC (Thu) by ewan (subscriber, #5533) [Link] Rubbish. The way to do this is to install a distribution suppliedkernel update that has the GPL driver patched into it. Automatically.
Quote of the week Posted Dec 16, 2004 16:30 UTC (Thu) by elanthis (subscriber, #6227) [Link] No, sorry, not happening. Distributions do not just release newer kernels with new hardware support. Especially with the new kernel development model. How can they? Do you know how many months a kernel goes through stability testing before a distribution (a serious one, not a toy one) releases that kernel? Vendors aren't just going to grab a new kernel with tons of new drivers, driver changes, massive internal changes, and make a release.
You only get updated kernels with new drivers and new features when you upgrade your entire OS. If you are using a toy distro like Fedora, that might not be so bad, although having to potentially wait 6 months for a piece of hardware to start working is insane when, with a stable API, it could work _now_. If you are using a stable distro, you might have to wait a year or more.
Quote of the week Posted Dec 17, 2004 1:58 UTC (Fri) by mbp (guest, #2737) [Link] You seem to think that merely backporting some drivers would be a much easier task than upgrading the whole kernel, but I don't think that's necessarily true. The driver tree is more than half the weight of the kernel on any given architecture, and I think accounts for much more than half the churn from one release to the next. Fully qualifying a large machine can take a month of stress tests, and obviously this heavily exercises the drivers.
People want to stay on a single kernel version because they don't want things to break. Upgrading device drivers is a good way to make things break.
Quote of the week Posted Dec 17, 2004 12:58 UTC (Fri) by mrshiny (subscriber, #4266) [Link] Upgrading all the device drivers would be a good way to break something,but on a given machine, the size of the kernel plus the size of all the RUNNING device drivers probably throws the weight of the code back to the kernel's side. And often it's a question of needing a single driver, especially if it's for a new piece of hardware on an otherwise unchanged computer.
Quote of the week Posted Dec 17, 2004 19:51 UTC (Fri) by giraffedata (subscriber, #1954) [Link] The device drivers are part of the kernel (whether or not they're part of a Linux package distributed on kernel.org, and whether they are bound into the base kernel or loaded at run time). The question is merely is it better to upgrade one kernel module (a particular device driver) or upgrade the entire kernel. While there's a possibility that upgrading a part causes a problem that upgrading the whole would not, I think it's pretty obvious here that upgrading just one device driver module is safer than adding a year's worth of development spread out over an entire kernel to your system. In fact, if upgrading one module didn't work because someone made an incompatible interface change, I would sooner patch the interface than bring in a whole new kernel.
Quote of the week Posted Dec 16, 2004 15:51 UTC (Thu) by gregkh (subscriber, #8) [Link] That is not how the Linux kernel development process works.
Please see http://www.kroah.com/log/linux/stable_api_nonsense.html for details as to why we do not support binary kernel modules at all.
Quote of the week Posted Dec 16, 2004 16:40 UTC (Thu) by elanthis (subscriber, #6227) [Link] And you have completely ignored my point.
Getting drivers in-tree *does not solve anything* for the users, because they are *still* forced to upgrade kernels to get new/fixed drivers.
Do kernel APIs change? Yes. Do they improve with changes? Yes. Your arguments however fall apart.
There is nothign wrong with keeping old interfaces around. You only need to keep them for the release series. Any module compiled against 2.6.0 should work on 2.6.20. If you want to break stuff, say it for 2.7. Is it really that hard? Other Open Source projects the size of the kernel or large manage it easily enough.
The kernel developers probably don't even see the problem. I wouldn't expect you to. Try installing the latest stable version of an enterprise Linux distro (RHEL, for example) and try getting some piece of hardware to work on it for which there was no driver at the distro's time of release. How do you get that hardware to work? Are you going to install a bleeding-edge, untested, unstable development kernel on your machine? Are the other bazillions changes in the kernel really necessary to get a single piece of hardware working? What about an install disc that needs, say, a disk controller driver. How do you get that driver for the disc? With the Linux model, you're screwed, you can't install the OS, you have to wait for a new version of the OS to be released potentially many, many months later in order to install it on your newish hardware.
Getting the driver in-tree doesn't help that.
I really don't care that much about kernel ABI. I'm 100% fine with you guys explicitly stating that *all* modules must be GPL compatible, with no exceptions. I don't care about binary-only modules. I'm just sick of perfectly GPL drivers requiring me to have developer knowledge to get working because I can't just install the driver on my already installed and stable machine that happens to have a new hardware upgrade. It's insane.
You don't have to stop evolving API. You just have to suck it up and keep the old API around until the next major release. Save the really big changes for development series. That's it.
Quote of the week Posted Dec 16, 2004 19:26 UTC (Thu) by gregkh (subscriber, #8) [Link] Sorry, but no, we do not keep old, broken, unsecure apis around. If they are broken, we fix them. If they are unsecure, we fix them. Both of these reasons are why we do not, and will not, have a stable in-kernel api.
And as for "why not just do this for drivers?" Remember that drivers are first-class kernel citizens. There is no difference to the kernel from a USB driver, or a filesystem from the point of view of the code.
And if you want to upgrade your enterprise release kernel's drivers, then talk to your enterprise distro about this. You are staying with a specific kernel version for some reason, and that has nothing to do with the way the kernel developers work.
And if you want to upgrade your wireless card's driver version, then talk to those developers about providing support for older kernel versions. I'm sure if you want to pay them, they would be glad to offer this kind of support :)
Quote of the week Posted Dec 16, 2004 20:35 UTC (Thu) by mrshiny (subscriber, #4266) [Link] I guess what you're saying is that the way kernel developers work is not the way users use the kernel.
Don't get me wrong, I think you and the rest of the Linux kernel team have done lots of great work. But, especially since there doesn't seem to be a stable kernel anymore, I feel that needs of the users are being forgotten. The users are staying with particular kernel versions because the kernel is a tool that gets a job done, and replacing the whole kernel to upgrade a single driver is a bad idea from a risk management perspective. Business users don't want variability, they want predictability. In the case of a kernel, if the kernel has a buggy api, so be it, if the kernel is getting the job done. Users don't care about API, or deadlocks. And a deadlock that occurs for other users but doesn't occur for me is irrelevant to my business.
As a kernel developer, you want to eliminate deadlocks and other bugs. But if a bug is not manifesting itself to all users, eliminating that bug at the cost of every user's drivers is a high price to pay. By increasing the functionality of the kernel for some users, who experienced a flaw, you reduce the functionality for other users (binary module users), who can no longer use their hardware, and you make life more difficult for the third class of users who want to use new hardware on an old kernel, but can't because the drivers need to be back-ported. You have to admit: in many cases it is possible to maintain backwards compatibility (at least on a source level) without jumping through hoops, even if an API is broken, or easy to mis-use.
Stable releases Posted Dec 17, 2004 2:17 UTC (Fri) by mbp (guest, #2737) [Link] There is a stable release: 2.6.8.1 works great for me. (ymmv) I'm going to stick with it until I need a new driver, or I get bored. The same strategy can work for you: find something that works, then quit fiddling. If you want stability, stop upgrading.
Having a stable release series is not meaningful when the user community is as diverse as for the kernel: what works well for you may be inadequate for someone else. Maybe you need support for new hardware, but to me that's just dangerous churn. Who gets to decide what is critical enough to go into the stable stream?
Stable releases Posted Dec 17, 2004 13:03 UTC (Fri) by mrshiny (subscriber, #4266) [Link] This is why the kernel needs a stable release, and drivers need to bereleased separately. If the kernel itself is working for you, you don't upgrade it. But if your drivers are inappropriate, you get new ones, and install them on your older kernel. Unfortunately we can't do that in the linux world because the kernel developers have decided (rightly or wrongly) that they don't want to support that use-case. Why should I need to upgrade my whole kernel to get a network card working? What if that network card is newer than my kernel, and the driver only exists on a newer kernel that doesn't have the same driver api? I am out of luck; even though my kernel works fine, I want to upgrade a single component in my whole computer but I now have to upgrade the whole kernel, and ALL the device drivers. What if a device driver I used to use is now broken? It's happened in the past.
Stable releases Posted Dec 17, 2004 20:11 UTC (Fri) by giraffedata (subscriber, #1954) [Link] This is why the kernel needs a stable release,Exactly. However, some of the discussion here seems to suggest that Greg and his peers should provide it. There's simply no reason to expect that. Instead, we need distributors, whom we pay to give us what we need, to provide a stable release. They can take high-reward low-risk changes from kernel.org and add those, and they can skip compatibility-busting changes (or, more likely, make the minor modification required to make the change backward compatible). Since distributors used to get a lot more free help with that from kernel.org (via the e.g. 2.4 "stable" series) than they do now, I'm still waiting to see if they step up to that responsibility with 2.6-based kernels.
Quote of the week Posted Dec 20, 2004 17:30 UTC (Mon) by mwilck (guest, #1966) [Link] You are ignoring the fact that a lot of important drivers, even if GPL, are developed out-of-tree, mostly by hardware manufacturers. This holds even for the venerable aic7xxx/aic79xx which used to be tied into the kernel very closely, but isn't anymore now.
These companies develop their driver code independently, and try to merge them into the mainline kernel once in a while. Usually they try to support a large range of kernel versions with their driver, both vanilla and vendor kernels. These codes quickly evolve into a nightmare of #ifdef's and #if LINUX_VERSION_CODE <= KERNEL_VERSION(...) constructs.
However, what else should a driver developer do? Hardware suppliers can hardly demand from their customers to always stick with the latest -mm kernel. They can't rely on RedHat or Novell to back-port the drivers for them, either, because RedHat and Novell have their own agendas.
IMO the very least kernel developers should do is make the different API versions cleanly discernible by CPP macros. That doesn't mean the old API has to remain in place, there must just be some CPP macro that the driver code can test that says the API has changed. E.g. if a field "foo" is added to "struct bar" then the respective patch should contain a line
#define __STRUCT_FOO_HAS_BAR 1
(or similar, you get it).
I know CPP is ugly, but this is the only safe way for external driver-suppliers to follow development without breaking things completely for older or vendor kernels.
I predict that sooner or later someone will have to come up with some sort of "kernel autoconf" tool only to be able to maintain a minimum level of source-code compatibility between the kernel core and drivers. That'll be a pretty sad day.
I am 100% for GPL drivers and 100% for improving the kernel at max speed. But to gloat about breaking the interface for external suppliers goes too far, and shows a lot of ignorance for the needs of everyone except the core developers.
Quote of the week Posted Dec 17, 2004 2:02 UTC (Fri) by mbp (guest, #2737) [Link] You complain to RedHat and/or the hardware vendor, and get them to release a new kernel package which supports the right driver. Installing random drivers yourself would void your expensive RedHat support contract and your even more expensive binary application certification. RedHat support new hardware in updates, sometimes by backporting to a previous kernel.
Leaving aside the RedHat model, you seem to be saying you would like to be able to use a driver released with (say) 2.6.10 without upgrading from 2.6.4. *Even if* Linux had backward-compatible driver interfaces (and I believe Greg when he says they're a bad idea), this wouldn't work. The new driver might depend on new features which don't exist in 2.6.4. The only fix for this is a manual backport, which could be done either by a distribution or by the driver maintainer.
What you want would require not only back- but forward-compatibility: in other words, all internal kernel interfaces must be frozen for the duration of a branch. That's an entirely different development model to what the kernel uses now, and it probably wouldn't scale up.
As Greg and others have offered: if *you* want to do a stable fork of the kernel at any point and backport only the changes you think worthwhile, feel free.
Quote of the week Posted Dec 17, 2004 13:07 UTC (Fri) by mrshiny (subscriber, #4266) [Link] You're right, a driver written for 2.6.10 might not work on 2.6.4. Butthe thing about a stable API is that people could write drivers for 2.6.0 and it would work on 2.6.10; that's what would happen in practice if vendors were trying to support a large number of linux users. Driver writers could make the choice about what they want to support, based on their users's needs, and write to that API. They could pick a version, and know that from that version on, the driver will work, until 2.8 comes out. With the current model, a driver written for 2.6.x may not work for 2.6.x-1 or 2.6.x+1.
Quote of the week Posted Dec 20, 2004 6:09 UTC (Mon) by rickmoen (subscriber, #6943) [Link] elanthis wrote:There is nothing wrong with keeping old interfaces around.[...] Despite purporting to reply to it, I notice you show no signs of having read Greg's essay, to which you were directed -- which is unfortunate, as it details precisely what's wrong with doing so, and why, accordingly, the kernel maintainers deliberately avoid doing so. I really strongly recommend that you get around to reading Greg's essay, which has the advantage of both commendably lucid writing and of speaking authoritatively. Rick Moen
Quote of the week Posted Dec 16, 2004 18:02 UTC (Thu) by jschrod (subscriber, #1646) [Link] You seem to miss elanthis point. This has nothing to do with binary modules. This has to do with upgrades of GPLed modules (e.g., ipw2100 WLAN drivers for Centrino chips, or RAID device support, etc). Such upgrades are done by distributions not as patches, but only from version to version. And no -- I don't want to upgrade my systems every three months; and actually also not every year, also I'm forced to it.
Having such a ridiculous short backward compatibility time frame (or even none at all) is one of the very big disadvantages of Linux, compared to proprietary operating systems like Solaris, AIX, or Win32-flavored ones.
The current kernel development approach is botched, from a user's point of view. Not for a developer, mind you; but for end-users.
Joachim
Quote of the week Posted Dec 16, 2004 19:30 UTC (Thu) by gregkh (subscriber, #8) [Link] No one is forcing you to not use Solaris, AIX, or Win32, if you like the way they have pseudo-backwards compatibility support (I say pseudo, as it's not always true, and there are often lots of catches to how it is implemented.)
As for end-users, stick with a distro that provides a recent, up-to-date kernel, with full support for a wide range of devices, if that is important to you. Debian and Gentoo both provide this, as does Fedora.
It's all a matter of what is important to you, as a user. So base what you use, on those decisions (enterprise kernel vs. Debian bleeding-edge.)
Also remember, Linux supports more devices than any other operating system, "out of the box." And the fact that we do do this, shows that something must be working properly with this model :)
Quote of the week Posted Dec 16, 2004 21:00 UTC (Thu) by mrshiny (subscriber, #4266) [Link] Linux may have more drivers that work "out of the box" than any other OS, but it has nearly no devices that work after the box is open. On all the commercial operating systems you can buy a device, install it, and install the driver, and the device works, even if the device was built long after that OS was released.
|
|
||||||||||||