Page 3 of 9 FirstFirst 12345 ... LastLast
Results 21 to 30 of 83

Thread: Have the drm.git kernel modules been abandoned?

  1. #21
    Join Date
    Feb 2009
    Posts
    165

    Default

    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

  2. #22
    Join Date
    Jan 2009
    Location
    UK
    Posts
    331

  3. #23
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,801

    Default

    Quote Originally Posted by Ant P. View Post
    Thanks. We now know why. We still think it sucks though. It kind of ignores reality and the real world.

  4. #24
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote Originally Posted by mdias View Post
    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.

  5. #25
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,572

    Default

    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.
    Last edited by bridgman; 09-20-2009 at 10:53 PM.

  6. #26
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    Quote Originally Posted by mdias View Post
    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.

  7. #27
    Join Date
    Jan 2008
    Posts
    157

    Default

    Quote Originally Posted by RealNC View Post
    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.

  8. #28
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,801

    Default

    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.
    Last edited by RealNC; 09-21-2009 at 03:59 AM.

  9. #29
    Join Date
    Aug 2008
    Posts
    77

    Default

    Quote Originally Posted by RealNC View Post
    "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?

  10. #30
    Join Date
    May 2008
    Posts
    99

    Default

    Quote Originally Posted by RealNC View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •