> 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
> 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
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
> 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.
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
> due to an out-of-tree driver from your board vendor [...]
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
> 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.
> 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?
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.