| |||||||||||||
out of treeout of treePosted Aug 3, 2009 4:47 UTC (Mon) by mikov (subscriber, #33179)In reply to: out of tree by johnflux Parent article: A tempest in a tty pot
What happens when you no longer support that hardware? What happens if your company goes bankrupt, reduces in size, etc, and can no longer support the out-of-tree driver? You then end up in a situation where users cannot ever upgrade their kernel because your out-of-tree driver is no longer being upgraded. Well, since the out-of-tree drivers still must be GPL, if the hardware manufacturer doesn't want to support it, anybody else can do it. Nothing changes in that respect. A stable API gives us best of both worlds. I worked for a company that has an out-of-tree driver. We ended up only officially supporting quite an old kernel. This screwed over customers that needed a newer kernel (typically for newer power management features)I completely agree that, as things are currently, an out-of-tree driver is a lot of work to maintain. That's precisely why I am arguing for a stable API. Then ideally an out-of-tree driver would work with any kernel. If there happen to be driver API changes (realistically those can't be avoided) they will be formally versioned and documented so porting will be routine.
(Log in to post comments)
out of tree Posted Aug 3, 2009 6:38 UTC (Mon) by johnflux (subscriber, #58833) [Link]
Out-of-tree drivers don't have to be GPL (well, that's a up to debate, but there are certainly proprietary drivers). And even if it's GPLed, if it's out of tree then there's a good chance that it doesn't meet the coding standards for inclusion into the kernel - for example a company typically might have a single source for Windows and Linux, with hundreds of #ifdef's to switch between them. There is also often a custom build system, revision control system, etc.
So this means that once the company goes bankrupt, some volunteer has to take code that he's probably never looked at before and undertake what could be a large task to clean up and adapt the driver for inclusion into the kernel.
out of tree Posted Aug 3, 2009 17:48 UTC (Mon) by mikov (subscriber, #33179) [Link] Out-of-tree drivers don't have to be GPL (well, that's a up to debate, but there are certainly proprietary drivers). That is not really true. I am not aware of anything that allows a Linux kernel driver to be non-GPL. The only gray area is if the driver has been ported from another OS, and this is also questionable. I have seen more than one clear statement from Linus Torvalds on this subject. There is no question that people violate the Linux GPL all the time. It is ethically disgusting (although I actually understand very well why they do it). But in any case, a stable source API has not relevance to that problem. And even if it's GPLed, if it's out of tree then there's a good chance that it doesn't meet the coding standards for inclusion into the kernel - for example a company typically might have a single source for Windows and Linux, with hundreds of #ifdef's to switch between them. There is also often a custom build system, revision control system, etc. And that is bad because? The current standards are needed because the kernel developers have to be able to "maintain" (more like coax into compiling) a mountain of drivers they don't care about. If the drivers are maintained by interested 3rd parties, it doesn't matter in the least, and those 3rd parties should choose whatever standards of their own they prefer. So this means that once the company goes bankrupt, some volunteer has to take code that he's probably never looked at before and undertake what could be a large task to clean up and adapt the driver for inclusion into the kernel. I am sorry but this is a logical fallacy. This volunteer is free to develop a driver of his own using his superior coding standards from day one. Plus, surely having an existing working driver is much better than starting from scratch. Look, I am well aware that the idea for a stable API is not popular and for sure I am not the best advocate for it. I actually don't think that a stable API will happen. But I also know what I am seeing in my professional life and it doesn't look good. Also (sorry to repeat myself) it is clear to me that with the current situation Linux will never be really successful on the desktop. The stable API is just one of the several reasons for that, but it isn't a small one.
out of tree Posted Aug 3, 2009 20:08 UTC (Mon) by johnflux (subscriber, #58833) [Link]
> I am sorry but this is a logical fallacy. This volunteer is free to develop a driver of his own using his superior coding standards from day one. Plus, surely having an existing working driver is much better than starting from scratch.
There's no logical fallacy there. I stated that an out-of-tree driver requires a lot of work to get into the kernel if it has to be done once the company has gone bankrupt, compared to if the driver was in the tree in the first place. But you're stating that an out-of-tree driver is easy than no driver at all which is true, but not really relevant to an in-tree or out-tree discussion.
I do get where you're coming from, but I do think that in the long run, Linux will have the bigger advantage of having all the drivers in tree.
The other day, for example, I need to get a webcam working on an ARM device. In linux it was easy because all the drivers were just there. I plugged in the webcam and it just worked.
Likewise I dread re-installing Windows because the drivers for my wireless card are difficult to get. The company that made the drivers has since gone and their website is now down.
out of tree Posted Aug 3, 2009 22:14 UTC (Mon) by mikov (subscriber, #33179) [Link] There's no logical fallacy there. I stated that an out-of-tree driver requires a lot of work to get into the kernel if it has to be done once the company has gone bankrupt, compared to if the driver was in the tree in the first place. But you're stating that an out-of-tree driver is easy than no driver at all which is true, but not really relevant to an in-tree or out-tree discussion. Well, you are implying that it is somehow "bad" to have an existing working GPL driver, which just happens to be out of tree. That is the fallacy. In fact it cannot possibly negatively affect the desired outcome, which is to have a working driver. I actually think that there should be no drivers in tree. That is an unmanageable situation - keeping all possible drivers in one monolithic source tree, and upgrading them at every kernel release. It should be obvious that this simply cannot scale. You cannot expect a finite number of developers to maintain a potentially infinite number of drivers for ever. The other day, for example, I need to get a webcam working on an ARM device. In linux it was easy because all the drivers were just there. I plugged in the webcam and it just worked. That sort of thing is simply not possible in Windows. That is a funny example because I have exactly the opposite experience with an embedded project. It is not possible to buy a working camera for it because its kernel can't practically be upgraded. And even with a modern kernel, I can't find a single webcam from Fry's to work on my Linux desktop. AFAIK, there is a very high turnover rate with webcam chips, so it simply does not make economic sense to maintain a driver for hardware whose life is 6 months. Now, if only there was a stable driver API ... :-) Likewise I dread re-installing Windows because the drivers for my wireless card are difficult to get. The company that made the drivers has since gone and their website is now down. I don't get it. Why would you have to re-install Windows for a single driver? Let's for a second forget about the labels Linux and Windows and look at it as impartial scientists performing an experiment. We have "OS A" which owns 99% of a market, and "OS B" which has 0.5% and doesn't seem to be growing even though it is much cheaper (!?!). What reasons could we have, as impartial scientists, to believe that "OS B" is somehow superior? Personally I obviously think that Linux is superior in many respects, or I wouldn't be here. But I am sure that that it is despite the lack of stable API, not because of it.
out of tree Posted Aug 3, 2009 22:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
what makes you think that the pool of developers to maintain the drivers in the kernel is finite while the pool of drivers is not?
the number of people who contribute to the kernel continues to grow.
you believe that the unstable API is a drawback, many others believe that is is a strength.
the people that you need to convince are not here, you need to go elsewhere to convince them.
out of tree Posted Aug 3, 2009 23:55 UTC (Mon) by mikov (subscriber, #33179) [Link] the people that you need to convince are not here, you need to go elsewhere to convince them. Do you mean this in the sense "shut up and go away"? I don't want to convince anybody. I think that a stable API is a lost cause, like Linux on the desktop, or Linux gaming. It is time to wake up and smell the flowers. The desktop PC is almost gone. I am curious about intelligent objections against a stable API, but I am not crazy to go get flamed on LKML. (If you do a search, there have been others, brave or stupid enough to post about a stable API there. LOL. Poor suckers. They deserved what was coming to them.) The people who would need convincing are the big companies who pay for Linux kernel development. It is more than a bit naive to think that volunteers in their free time can influence Linux at this point of its development. But I have a pretty good theory why RedHat, Novell, etc, aren't interested in a stable API.
out of tree Posted Aug 4, 2009 0:38 UTC (Tue) by foom (subscriber, #14868) [Link]
I'm pretty sure I don't use any 3rd party drivers on my Mac laptop, and I certainly haven't missed
them or thought MacOS was not ready-for-the-desktop because of it...
out of tree Posted Aug 4, 2009 4:47 UTC (Tue) by mikov (subscriber, #33179) [Link]
Yeah right. Which parts of your Mac did you buy from a different hardware vendor?
out of tree Posted Aug 3, 2009 22:29 UTC (Mon) by johnflux (subscriber, #58833) [Link]
Well, you are implying that it is somehow "bad" to have an existing working GPL driver, which just happens to be out of tree.
_Compared_ to having it in tree. That's all I've ever said.
> That is the fallacy. In fact it cannot possibly negatively affect the desired outcome, which is to have a working driver.
Compared to not having it at all, sure.
> That is a funny example because I have exactly the opposite experience with an embedded project. It is not possible to buy a working camera for it because its kernel can't practically be upgraded.
Why can't it be upgraded? Because of an out-of-tree driver? :-D
> And even with a modern kernel, I can't find a single webcam from Fry's to work on my Linux desktop.
I find that unlikely :-) I've bought 4 webcams randomly, 2 built into laptops, and all just worked in linux.
> I don't get it. Why would you have to re-install Windows for a single driver?
Nah, I meant that if I re-install, for an unrelated reason, then I have trouble getting the drivers.
out of tree Posted Aug 3, 2009 23:38 UTC (Mon) by mikov (subscriber, #33179) [Link] Why can't it be upgraded? Because of an out-of-tree driver? :-D Laugh all you want :-) But it is a real problem that should not exist... Ignoring it doesn't make it any less important for the developers and users of this product. I find that unlikely :-) I've bought 4 webcams randomly, 2 built into laptops, and all just worked in linux. Well, I am not making it up. BTW, I am running Kubuntu LTS and Debian Stable on my desktops. Perhaps you see my problem? ;-) Nah, I meant that if I re-install, for an unrelated reason, then I have trouble getting the drivers. Well, that is the problem of closed source, no argument from me there. BTW, you can still save the drivers. You have to copy the INF file and the files referenced from it and you can reinstall them on a new system without any tricks. Some things in Windows really are that easy :-)
out of tree Posted Aug 4, 2009 8:06 UTC (Tue) by farnz (guest, #17727) [Link] The thing is, and this is from direct personal experience, companies maintaining out of tree drivers don't put their driver through the Linux code review process; as a result, they ignore standard Linux interfaces in favour of inventing their own. Add to that the fact that they lose interest in maintaining their driver at all when they've moved onto the new shiny (in the case of one vendor I've dealt with, the driver stops being maintained as soon as they have a new chip out, even though they're still selling the old chip), and the fact that I don't have the time to do more than bugfix drivers that have already been ported to new APIs, and I find myself thinking that all the advantages you claim for out of tree drivers are disadvantages from my perspective. I want one place to go to for drivers. Not twenty trees, but the one tree on kernel.org. I have found it easier to backport drivers from 2.6.30 to 2.6.23 than to integrate vendor drivers, so I would prefer in- aiming to move into the tree (before GregKH's staging area), and that was quite enough pain. I'm also afraid that your admission that you're stuck on an old kernel due to an out-of-tree driver from your board vendor reminds me of a subset of nVidia graphics card owners, who complain bitterly (regardless of technical reasons) when X.org releases a new version of the X server that isn't backwards compatible with the ancient version of the nVidia drivers that supports their older hardware; I do feel that you should be exerting pressure on your vendor to make this happen, either by getting their drivers into the kernel, or getting them to step up and do the work of maintaining a stable in-kernel API. It's not going to come for free, so why shouldn't the people who want such an API do the work of maintaining it?
out of tree Posted Aug 4, 2009 20:51 UTC (Tue) by mikov (subscriber, #33179) [Link]
> The thing is, and this is from direct personal experience, companies
> maintaining out of tree drivers don't put their driver through the Linux > code review process; as a result, they ignore standard Linux interfaces > in favour of inventing their own.
I have no opinion about this because I haven't personally experienced it, but I believe you. But why isn't this a problem in Windows?
> Add to that the fact that they lose interest in maintaining their driver
Agreed, but what is your point? You are describing exactly the problems caused by a lack of stable API. Vendors do not want to maintain drivers for hardware which they no longer sell, because it is a never ending cycle of completely pointless but expensive work (from their standpoint). That would not be the case if there was a stable API.
First, it would be very cheap for them to continue the maintenance, so they would likely do it. Second, even if they didn't, the driver should just continue to work. And lastly, a volunteer can pick it up at any moment.
> I want one place to go to for drivers. Not twenty trees, but the one
Well, that is you but you are the exception. 99.9% of the Linux users and most of the developers can't backport a driver. While I personally also could do it, there is more than that - for example I don't really have time or support such backported driver in a business setting.
There is definite value in a central repository for drivers. The problem with the current approach is that the release cycles of all drivers are tied together. Ideally I would like to see a central repository where vendors are free to upload their drivers whenever they want.
> I'm also afraid that your admission that you're stuck on an old kernel
I have never said that. I mentioned a problem where newer webcam drivers are only available for new kernels. This has nothing to do with in-tree vs out-of-tree drivers; it is precisely a matter of lack of stable API.
It seems that many people who responded negatively to my comments here are confusing a couple of related by separate issues:
* Stable API. It is equally beneficial to in-tree and out-of-tree drivers because in either case it decreases the maintenance burden. In fact contrary to the common wisdom, a stable API gives more freedom to core developers to make changes because they can keep them isolated behind the facade of the stable API.
* In-tree vs out-of-tree drivers. It is true that a stable API decreases the incentive to submit drivers to the kernel because the "free maintenance" red herring is gone. But if people perceive value in having a central point for driver development, there is nothing stopping them.
* Closed source drivers. This is completely unrelated to a stable source level API. They are prohibited by the kernel license and suffer from their well known problems.
> reminds me of a
I would like to see an open source Nvidia driver as much as the next guy, but I have to disagree with you. How did Microsoft manage to keep their graphics driver API the same from NT 3.1 to Windows XP? To think that it is a bad thing is to ignore reality.
> I do feel that you should be
Agreed in theory. But you are forgetting that these vendors don't need to support Linux at all. It is less than 1% of their market, but it takes more work to support that Windows. So, why the hell would they do it at all?
So, they don't have to do anything. It is not their problem. If the Linux community wants to bring these vendors fully on board, it should make it easy for them. Easier than Windows. The major factor for "easiness" is stable APIs.
out of tree Posted Aug 5, 2009 10:32 UTC (Wed) by farnz (guest, #17727) [Link] > The thing is, and this is from direct personal experience, companies > maintaining out of tree drivers don't put their driver through the Linux > code review process; as a result, they ignore standard Linux interfaces > in favour of inventing their own. I have no opinion about this because I haven't personally experienced it, but I believe you. But why isn't this a problem in Windows? It is a problem in Windows, too; for example, very few graphics card drivers support Windows native screen rotation in XP - you need to use a vendor utility instead. The difference is that Windows users are used to this, and don't complain as loudly about it. It's becoming less of an issue as things like USB standardize more and more device classes, and manufacturers use the standard classes, because that means that the device is Plug And Play under currently shipping Windows systems (Vista, future Windows 7 installs). > Add to that the fact that they lose interest in maintaining their driver > at all when they've moved onto the new shiny (in the case of one vendor > I've dealt with, the driver stops being maintained as soon as they have > a new chip out, even though they're still selling the old chip), and the > fact that I don't have the time to do more than bugfix drivers that have > already been ported to new APIs, and I find myself thinking that all the > advantages you claim for out of tree drivers are disadvantages from my > perspective. Agreed, but what is your point? You are describing exactly the problems caused by a lack of stable API. Vendors do not want to maintain drivers for hardware which they no longer sell, because it is a never ending cycle of completely pointless but expensive work (from their standpoint). That would not be the case if there was a stable API. Oops - my bad. I forgot to mention that the case in question was migrating from NT4 to XP in an embedded product. We could still buy the chips in question, but the NT4 driver didn't work in XP, even after we recompiled it against the new DDK (don't know why - I thought there was a stable API?). We ended up having to buy new ASI capture chips, and scrapping the older hardware. > reminds me of a > subset of nVidia graphics card owners, who complain bitterly (regardless > of technical reasons) when X.org releases a new version of the X server > that isn't backwards compatible with the ancient version of the nVidia > drivers that supports their older hardware; I would like to see an open source Nvidia driver as much as the next guy, but I have to disagree with you. How did Microsoft manage to keep their graphics driver API the same from NT 3.1 to Windows XP? To think that it is a bad thing is to ignore reality. They didn't keep the graphics driver API the same from NT 3.1 to Windows XP. Newer OSes cannot run graphics cards using older drivers, pure and simple. No different to Linux, in that respect. And note that vendors do need to bring the Linux community on board - my employer alone buys a significant number of TV capture cards a month, on condition that they are supported under Linux. We pay a slight premium to buy Hauppauge cards because of the Linux support; other vendors are £5/card cheaper, but cost huge amounts of money in expensive developer time keeping the card going.
out of tree Posted Aug 5, 2009 18:05 UTC (Wed) by mikov (subscriber, #33179) [Link] It is a problem in Windows, too; for example, very few graphics card drivers support Windows native screen rotation in XP - you need to use a vendor utility instead. I don't want to defend Windows, but IIRC that is technically wrong. Unless I am mistaken, XP does not support native screen rotation. It was introduced in Vista. I do agree with your general point that you can't rely on the vendors to "do the right" thing. Vendors do suck. I have seen really really horrible disgusting things working with closed source drivers. But this is an impossible battle. You can't require all developers for your OS to be perfect. People will do whatever they want to do. The best you can do is give them tools encouraging them in the right direction. Plus, hopefully GPL will shame them into better code. Look at Google Android. They are basically doing whatever they want with the kernel and not bothering to submit anything back. They didn't keep the graphics driver API the same from NT 3.1 to Windows XP. Newer OSes cannot run graphics cards using older drivers, pure and simple. No different to Linux, in that respect. I am sorry but that is not quite true either. In a previous life I used to do Windows kernel development, and graphics drivers specifically. I have ported drivers from NT4 to W2K and WXP. The API remained backwards compatible and even binary compatible. In NT4 they did a fundamental architectural change by moving the drivers into the kernel, but the source level API remained compatible with NT 3.51. And note that vendors do need to bring the Linux community on board - my employer alone buys a significant number of TV capture cards a month, on condition that they are supported under Linux. We pay a slight premium to buy Hauppauge cards because of the Linux support; other vendors are £5/card cheaper, but cost huge amounts of money in expensive developer time keeping the card going. I don't quite follow. Can you please clarify a bit? Why do the other cards need huge amounts of money? Also, you are saying that Hauppauge is more expensive because it has to support Linux. So, how is that a good thing?
out of tree Posted Aug 5, 2009 18:15 UTC (Wed) by johnflux (subscriber, #58833) [Link]
> I don't quite follow. Can you please clarify a bit? Why do the other cards need huge amounts of money? Also, you are saying that Hauppauge is more expensive because it has to support Linux. So, how is that a good thing?
I think his point was that his company was willing to pay extra just for linux support. So Hauppauge was able to charge more money, and still get his custom. Whereas the companies that didn't support Linux didn't get his business.
From a business point of view, if the money that a company loses because of their lack of linux support is greater than the cost of opening the specs or writing the drivers, then the company should write Linux drivers. The poster was providing anecdotal evidence to indicate that they believe that this is the case for some (most?) companies.
On a personal note, I think companies perceive the cost of opening their drivers to be far higher than it really is.
out of tree Posted Aug 5, 2009 18:45 UTC (Wed) by farnz (guest, #17727) [Link] Hauppauge cards tend to work out of the box with a recent enough kernel; when they don't, Hauppauge employees are happy to help you make the cards work. Other vendors cards require developer time to make work, and attempts to get the vendor to help tend to be fruitless (they have their own out of tree driver that doesn't work well, due to reinvention of interfaces, and don't understand why you won't simply rewrite your userspace to match their driver). Developer time is hugely expensive, as we don't have much to spare; given the choice between a small amount of extra money per card (to the vendor), or developer time, we'd rather pay. If you're a vendor, looking to expand, this is a market, and it has money to spend on you.
out of tree Posted Aug 6, 2009 6:28 UTC (Thu) by lysse (guest, #3190) [Link]
> this is from direct personal experience
So why are you generalising from it?
out of tree Posted Aug 6, 2009 8:10 UTC (Thu) by farnz (guest, #17727) [Link] I'm generalising from experience of 15 to 20 vendors, of whom only a couple had their drivers upstreamed. The remainder simply did not understand why (to use some examples) I didn't want to use their vendor- specific DVB-T tuning interface instead of Linux's DVB API, or their vendor-specific video capture interface instead of V4L2. However, I recognise that my experience may be atypical; I therefore mention that I base this on personal experience, so that if I've just had bad luck with vendors, other people can point out vendors who get it right.
out of tree Posted Aug 7, 2009 22:31 UTC (Fri) by Los__D (guest, #15263) [Link]
This is not much different on Windows.
Stupid devices which needs stupid programs to do what a perfectly capabable standard Windows configuration tool should be doing seems to be more the rule that the exception.
- The worst part is that Windows seems to support that ridiculous way of doing it. i.e. the Wi-Fi configuration tool has an option to transfer control to a 3rd party program.
(To be fair, this seems to be getting a bit less frequent lately).
|
|||||||||||||