Have the drm.git kernel modules been abandoned?

[mdias]

I'd also like to voice my opinion against this "way that linux works".
Drivers should be seperate modules.
If the kernel is always changing in a way that makes drivers incompatible, then THAT's the problem. And this is the kind of stuff that makes linux impossible to get mainstream usage...

It all feels like there are no standards to follow and everyone just do whatever they want instead of working cooperatively. I don't know much about decisions that made linux what it is today, but why didn't anyone make a standard driver interface for linux yet? The way PC hardware works doesn't change all that much, so why is the kernel way of comunicating with hardware doing so?

Before people start flaming me or just saying "you're free to do so yourself", well, I don't have the time to do so, and maybe not the skills either.

~end of probably uneducated rant

[Ant P.]

Educate yourself then.

[RealNC]

Educate yourself then.

Thanks. We now know why. We still think it sucks though. It kind of ignores reality and the real world.

[pvtcupcakes]

I'd also like to voice my opinion against this "way that linux works".
Drivers should be seperate modules.
If the kernel is always changing in a way that makes drivers incompatible, then THAT's the problem. And this is the kind of stuff that makes linux impossible to get mainstream usage...

It all feels like there are no standards to follow and everyone just do whatever they want instead of working cooperatively. I don't know much about decisions that made linux what it is today, but why didn't anyone make a standard driver interface for linux yet? The way PC hardware works doesn't change all that much, so why is the kernel way of comunicating with hardware doing so?

Before people start flaming me or just saying "you're free to do so yourself", well, I don't have the time to do so, and maybe not the skills either.

~end of probably uneducated rant

If Windows updated it's kernel as often as Linux, they'd have the same problem too. Only it'd be worse because you'd be relying on Vendors to update their drivers.

[bridgman]

The enterprise and LTS distros are really the counterpart to Windows, not the fast moving ones.

It probably helps if you think about the fast moving distros as a view into the enterprise distros coming a year or two from now, which *will* have a stable driver interface.

[agd5f]

I'd also like to voice my opinion against this "way that linux works".
Drivers should be seperate modules.
If the kernel is always changing in a way that makes drivers incompatible, then THAT's the problem. And this is the kind of stuff that makes linux impossible to get mainstream usage...

It all feels like there are no standards to follow and everyone just do whatever they want instead of working cooperatively. I don't know much about decisions that made linux what it is today, but why didn't anyone make a standard driver interface for linux yet? The way PC hardware works doesn't change all that much, so why is the kernel way of comunicating with hardware doing so?

The interface to userspace is stable, it's just the internal kernel APIs that change. It makes it much easier to undo stupid designs or move to more efficient algorithms as things progress. Since the drivers are mostly all in the tree they get updated when the interface changes. If internal interfaces had to stay around forever, the kernel would fill with bloat as new stuff kept got added onto the old t avoid breaking old out of tree drivers that use old interfaces and never get changed.

[rvdboom]

Thanks. We now know why. We still think it sucks though. It kind of ignores reality and the real world.

That's a bit exagerated. I usually compile my own kernel with every new release, copying my .config file from one tree to the other and checking if there's nothing new or changed. It's not really that big a hassle now with the fast processors and it's been at least two years I've not seen any real regression doing this, which shows quality control has greatly improved in the kernel development.
I believe having separate drivers is just something one misses when one wants desperately to get a Windows way of managing its system, but I find it hardly necessary.
In fact, not having to check around several vendors to get driver updates is actually nice.

[RealNC]

OK, I'm certainly no expert on the matter, but AFAIK, Solaris has such a driver interface, and mostly positive things came out of it. For Linux that would mean more manufacturers, who are not able/willing to open source their code, offering Linux drivers.

"Get your driver in the kernel" is an extremely naive suggestion; do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel? (Those are just two examples, there are many more.) Also, except of being naive, the suggestion can turn out to be deceptive: after opening up the drivers, there's a very big chance of "we won't push this crap code into the kernel" response. Or no one is actually willing to include the driver; Marvell opened up their ethernet driver at some point (GPL), but no one ever has put it in the kernel; to this day, the "sky2" kernel driver is still used even though it has bugs. They expect Marvell to do it.

So companies not only have to get all the legalese and paperwork solved to open their drivers, they also have to work extra to actually adapt it for kernel inclusion. Yeah sure, "open up the specs so we can write drivers." They open the specs, no one writes drivers. Then, "open up the source code for your drivers." Er, OK, we gave you the specs, you didn't write any drivers, so fine, here's the freaking source code, take it. Oh noes, no one includes it in the kernel... "Rewrite your driver and beg on LKML for acks". There's only one response really: "Screw you. I'm out. I'm not prepared to waste ten times more resources for a market ten times smaller."

I don't blame them the least for not doing all the above. It's not worth the effort. And Linux isn't helping them even though according to simple logic, it should (they don't need Linux; Linux needs *them*).

This situation is the main reason I think that a major part of "The Linux Kernel Driver Interface" document is bollocks and Greg Kroah-Hartman not really thinking before writing. The technical reasons seem logical though.

[nhaehnle]

"Get your driver in the kernel" is an extremely naive suggestion;

It's working pretty well in reality, don't you agree?

do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel? (Those are just two examples, there are many more.)

Please. Yes, there is a lot of work going into those graphics drivers, so I can understand where they're coming from. But the general rule is that drivers aren't that big a deal, the graphics market is the rare exception here.

Also, except of being naive, the suggestion can turn out to be deceptive: after opening up the drivers, there's a very big chance of "we won't push this crap code into the kernel" response.

If the code really is crap, then why would you want to run it as a binary blob?

[Vash63]

OK, I'm certainly no expert on the matter, but AFAIK, Solaris has such a driver interface, and mostly positive things came out of it. For Linux that would mean more manufacturers, who are not able/willing to open source their code, offering Linux drivers.

"Get your driver in the kernel" is an extremely naive suggestion; do you see NVidia or AMD being able or willing to get their binary blobs opened and included in the kernel? (Those are just two examples, there are many more.) Also, except of being naive, the suggestion can turn out to be deceptive: after opening up the drivers, there's a very big chance of "we won't push this crap code into the kernel" response. Or no one is actually willing to include the driver; Marvell opened up their ethernet driver at some point (GPL), but no one ever has put it in the kernel; to this day, the "sky2" kernel driver is still used even though it has bugs. They expect Marvell to do it.

So companies not only have to get all the legalese and paperwork solved to open their drivers, they also have to work extra to actually adapt it for kernel inclusion. Yeah sure, "open up the specs so we can write drivers." They open the specs, no one writes drivers. Then, "open up the source code for your drivers." Er, OK, we gave you the specs, you didn't write any drivers, so fine, here's the freaking source code, take it. Oh noes, no one includes it in the kernel... "Rewrite your driver and beg on LKML for acks". There's only one response really: "Screw you. I'm out. I'm not prepared to waste ten times more resources for a market ten times smaller."

I don't blame them the least for not doing all the above. It's not worth the effort. And Linux isn't helping them even though according to simple logic, it should (they don't need Linux; Linux needs *them*).

This situation is the main reason I think that a major part of "The Linux Kernel Driver Interface" document is bollocks and Greg Kroah-Hartman not really thinking before writing. The technical reasons seem logical though.

Um, exactly what drivers are you talking about Linux needing? I can't really think of any major products that aren't supported. Marvell chips work fine with sky2, the specs being open means the driver was done in the main tree... just because their "official" driver isn't there doesn't mean the hw is unsupported. If their driver is GPL'd yet still not included while there is already sky2, I'm sure there's a good technical reason for that.