8 ms·

Intel Thunder Bay is officially canceled, Linux driver code to be removed

115 points by nippoo 4y ago

stonogo 4y ago
Why do the kernel developers allow corporations to shove code into the tree for hardware nobody has? Google does this too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/google/Kconfig https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?
- toast0 4y ago
  Because everyone is better off if distribution kernels get the hardware support before the hardware is purchased.
- dboreham 4y ago
  Because kernel developers are paid by same corporations?
- charcircuit 4y ago
  As long as its being maintained by them and isn't adding to their maintainence burden why care?
- kardos 4y ago
  I think the idea is that the hardware will work under linux right away when the hardware goes on sale, instead of some number of months or years later. Surely that amounts to a selling point. > now we're left with useless crap in the kernel. The article is specifically about removing the now-useless crap, and the removal patches were submitted by Intel. I don't see how Intel is doing anything wrong here.
  - rektide 4y ago
    Further, the code is in a fairly-well-isolated easy-to-blow-away staging area of the kernel, specifically designated for early-stage work.
  - Gigachad 4y ago
    Especially since many distros use old kernels, getting the drivers in months before release means stuff will just work no matter which distro.
- nephyrin 4y ago
  > if that person quits or the company discontinues a product, now we're left with useless crap in the kernel Presumably deleting code is not very hard if it is unmaintained or a burden. > Why can't these companies just build their own modules? Why is it everyone else's problem? They're not upstreaming this so their own internal dev lives are easier. They'd rather just keep using whatever development repo they already are without dealing with upstream reviews and requirements. They were upstreaming this so that everyone could have support for the hardware upon release. And, to that end, "corporations" upstreaming high quality support for their hardware, as intel has been doing, benefits linux. Throwing shade at them for preparing day-1 support for hardware they ended up canceling seems counter-intuitive.
- jjoonathan 4y ago
  As a user, it seems much more likely to become my problem if it isn't baked in.
- azurezyq 4y ago
  Because linux just doesn't have a good driver stack like WDM. Everything is better just built into the kernel. Kernel module just cannot solve all problems.
- monocasa 4y ago
  > I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem? Because if it gets truly abandoned, the kernel folk are generally pretty good at ripping it out. And the idea is that supporting weird cases off and on will lead to a more general kernel that will be able to attack future needs for everyone a little better.
- witheld 4y ago
  You’re practically not supposed to to build external modules. It’s supported to only the most minimal degree- Linus, and the Linux project, WANT you to build things in. And as everyone else has told you, this is so that support for hardware is in Linux and in distros BEFORE users have to taint their kernels and create crazy bugs kernel devs have to deal with.
  - worthless-trash 4y ago
    > WANT you to build things in. Only if you adhere to their standards, until very recently you couldn't even do rust. If i made something fully working in rust today it still wouldn't get accepted.
    - witheld 4y ago
      That’s exactly why they want you to do it with them though- so they can make you do it too their standards.
      - IshKebab 4y ago
        No it isn't. The reason you can't write external modules is because the kernel interfaces aren't stable. You would have to provide a module binary for every single kernel version (and maybe even for different configurations). And the reason for that is mostly that providing a stable interface is a) a ton of work, and b) would make distributing closed source drivers easier which is something Linus hates.
        witheld 4y ago
        if you read the mailing list, you know there’s a lot of reasons. Linus hates out of tree and closed modules for quite a number of reasons- but in this specific context it seems the most relevant.
- matheusmoreira 4y ago
  Because then consumers get hardware that works out of the box on Linux. That's how good corporations contribute. https://youtu.be/fMeH7wqOwXA&t=420s https://youtu.be/fMeH7wqOwXA&t=420s
- not2b 4y ago
  Because if they don't allow these kinds of code contributions, and wait until products are shipping to accept code, upstream Linux will be a year or more behind when new chips get shipped, and users will have to run out-of-tree forks of questionable quality. And in this case, the now-useless crap is being removed from the kernel.
- dathinab 4y ago
  Maintaining out of tree kernel modules and guaranteeing compatibility is a nightmare. Partially because in difference to the strict backward compatibility guarantees of the Linux user interface there are no such (strict) guarantees for the kernel interface. In the end this is both grate for Linux and Intel (and Nvidea, Amd, etc.): - kernel developers can make sure their code doesn't brake vendor code, this isn't just about being nice to vendors but about being able to do large internal refactoring which affect many/all kernel modules in a small way (good for both, in case of not yet released and in rare cases internal only hardware mainly for the vendor) - kernel developers can see how the kernel is used and where there might be problems with the current kernel interface and design (good for Linux) - kernel developers can enforce a certain minimal level of code quality or not allow hacks which would lead to serve security issues or incompatibilities (good for Linux) - it's much easier to make sure that different drivers/kernel modules don't conflict in subtle ways (good for both Linux and vendors) - customers buying the hardware often can use it from release date without needing custom kernels (good for everyone) - abandoned drivers/modules can be picked up and maintained by 3rd parties allowing longer usage of otherwise no longer supported hardware Lastly while companies like Intel do not own Linux they are some of the main contributors of financial resources often more then covering any additional costs caused by this (I mean for server hardware and more powerful embedding hardware Linux strongly dominates the marked and it's also one of the main markets for Intel, Amd, Nvidea and one of the main building blocks for companies like Google). Anyway this is good for everyone and in _total_ reduces the amount of work involved in making Linux work with all kinds of hardware.
- eklitzke 4y ago
  For the point about the Google firmware modules, the firmware directory you linked to is specifically for Chromebooks, which people do have, and the modules are useful if you want to run vanilla Linux with coreboot on this hardware. If the code for these modules was maintained out of tree it would be much harder to run a regular Linux distribution on the hardware as you'd have to go build a custom kernel rather than just reconfiguring and rebuilding the kernel your distro provides. Furthermore the whole point of modules on Linux is that you can completely disable them, or if they're built as modules they'll only be loaded if needed (in some cases this is done on-demand automatically if the relevant hardware is detected, in other cases it might be done via logic in your initrd).
- yxhuvud 4y ago
  Eh, because it is nice to be able to buy hardware on release day and actually have it work.
- msla 4y ago
  > Why do the kernel developers allow corporations to shove code into the tree for hardware nobody has? Google does this too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/google/Kconfig https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... To get the code ready for when the hardware is available. > I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem? A lot of companies and individuals can step up to maintain the code once it's there and working. If it's important, they will and they have. Only dead-dead systems like the 80386 get removed; or, in this case, vaporware that never materialized to begin with. Modules are bad because they're code that isn't subject to the same review as normal kernel code, may be closed-source or under some obnoxious license, and probably is going to be more difficult to install than just a kernel update. So we want it to be "everyone else's problem" because that means anyone else can step up if a company fires the people maintaining the code for hardware the kernel team still wants to support. With a module, it might be the case that the module only works on some range of kernels and is very difficult to replicate its functionality on more modern ones once the original company drops out. That's not a good position to be in if you rely on being able to run modern Linux on that hardware.
  - deleted 4y ago
    [deleted]
- steponlego 4y ago
  Linux hasn't been a community project in decades. It's basically run by a consortium of the biggest Chinese and American companies. And especially since Linus went away for his vacation-style treatment a few years ago, it's been getting much much worse.
beebeepka 4y ago
In other intel news, Raja is no longer with them. Seems like he was forced out and some of the rumours about the bleak future of their consumer GPU business may turn out to be true
- cbozeman 4y ago
  Turns out the leadership of Intel is stupider than I thought. It's almost impossible to believe that they actually thought they'd be able to go up against two GPU makers each with 25+ years of experience. This was always going to be a long uphill battle. Always. I figured it would take at least 10 years for Intel to become competitive, but turns out they tucked tail and ran. Mediocre!
  - gfv 4y ago
    Intel has been making GPUs since roughly 2002, 845 chipset series. (There were earlier ones, but I'm
    - userbinator 4y ago
      Intel740, 1998.
      - ChancyChance 4y ago
        I was on the team that wrote the DirectX 3 and 5 drivers for the 740 (I wrote the vxds in assembly using MASM 6.11). It wasn't a GPU in today's terms (huge parallel vector engines), it was just a basic 3d pipeline: triangle pipe (with Gouraud lighting, 1st version didn't even have phong/specular) followed by rasterizer, with a 2D engine. You sent it triangles with aRGB color, and it interpolated and rasterized them. Dat's it. Total dud compared to Voodoo 3DFx or ATI Rage3D. But when we integrated it into the 810 chipset it became the main reason why 3D gaming was held back for a decade: it was the top selling graphics engine but it sucked so every game dev had to design for the lowest common denominator. It was never intended to be good. But it sure did result in the promotion of a lot of engineers to principal. (raises hand)
neom 4y ago
Weird I was born in Thunder Bay, thought maybe they were opening a plant there that got cancelled. Wonder why they called it Thunder Bay Harbor, especially because Thunder Bay is a harbor town...
DeathArrow 4y ago
Thunder Bay went to play with Larabee between the stars.

115 points by nippoo 4y ago

Why do the kernel developers allow corporations to shove code into the tree for hardware nobody has? Google does this too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/google/Kconfig https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem?

toast0 4y ago
Because everyone is better off if distribution kernels get the hardware support before the hardware is purchased.
dboreham 4y ago
Because kernel developers are paid by same corporations?
charcircuit 4y ago
As long as its being maintained by them and isn't adding to their maintainence burden why care?
kardos 4y ago
I think the idea is that the hardware will work under linux right away when the hardware goes on sale, instead of some number of months or years later. Surely that amounts to a selling point. > now we're left with useless crap in the kernel. The article is specifically about removing the now-useless crap, and the removal patches were submitted by Intel. I don't see how Intel is doing anything wrong here.
- rektide 4y ago
  Further, the code is in a fairly-well-isolated easy-to-blow-away staging area of the kernel, specifically designated for early-stage work.
- Gigachad 4y ago
  Especially since many distros use old kernels, getting the drivers in months before release means stuff will just work no matter which distro.
nephyrin 4y ago
> if that person quits or the company discontinues a product, now we're left with useless crap in the kernel Presumably deleting code is not very hard if it is unmaintained or a burden. > Why can't these companies just build their own modules? Why is it everyone else's problem? They're not upstreaming this so their own internal dev lives are easier. They'd rather just keep using whatever development repo they already are without dealing with upstream reviews and requirements. They were upstreaming this so that everyone could have support for the hardware upon release. And, to that end, "corporations" upstreaming high quality support for their hardware, as intel has been doing, benefits linux. Throwing shade at them for preparing day-1 support for hardware they ended up canceling seems counter-intuitive.
jjoonathan 4y ago
As a user, it seems much more likely to become my problem if it isn't baked in.
azurezyq 4y ago
Because linux just doesn't have a good driver stack like WDM. Everything is better just built into the kernel. Kernel module just cannot solve all problems.
monocasa 4y ago
> I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem? Because if it gets truly abandoned, the kernel folk are generally pretty good at ripping it out. And the idea is that supporting weird cases off and on will lead to a more general kernel that will be able to attack future needs for everyone a little better.
witheld 4y ago
You’re practically not supposed to to build external modules. It’s supported to only the most minimal degree- Linus, and the Linux project, WANT you to build things in. And as everyone else has told you, this is so that support for hardware is in Linux and in distros BEFORE users have to taint their kernels and create crazy bugs kernel devs have to deal with.
- worthless-trash 4y ago
  > WANT you to build things in. Only if you adhere to their standards, until very recently you couldn't even do rust. If i made something fully working in rust today it still wouldn't get accepted.
  - witheld 4y ago
    That’s exactly why they want you to do it with them though- so they can make you do it too their standards.
    - IshKebab 4y ago
      No it isn't. The reason you can't write external modules is because the kernel interfaces aren't stable. You would have to provide a module binary for every single kernel version (and maybe even for different configurations). And the reason for that is mostly that providing a stable interface is a) a ton of work, and b) would make distributing closed source drivers easier which is something Linus hates.
      - witheld 4y ago
        if you read the mailing list, you know there’s a lot of reasons. Linus hates out of tree and closed modules for quite a number of reasons- but in this specific context it seems the most relevant.
matheusmoreira 4y ago
Because then consumers get hardware that works out of the box on Linux. That's how good corporations contribute. https://youtu.be/fMeH7wqOwXA&t=420s https://youtu.be/fMeH7wqOwXA&t=420s
not2b 4y ago
Because if they don't allow these kinds of code contributions, and wait until products are shipping to accept code, upstream Linux will be a year or more behind when new chips get shipped, and users will have to run out-of-tree forks of questionable quality. And in this case, the now-useless crap is being removed from the kernel.
dathinab 4y ago
Maintaining out of tree kernel modules and guaranteeing compatibility is a nightmare. Partially because in difference to the strict backward compatibility guarantees of the Linux user interface there are no such (strict) guarantees for the kernel interface. In the end this is both grate for Linux and Intel (and Nvidea, Amd, etc.): - kernel developers can make sure their code doesn't brake vendor code, this isn't just about being nice to vendors but about being able to do large internal refactoring which affect many/all kernel modules in a small way (good for both, in case of not yet released and in rare cases internal only hardware mainly for the vendor) - kernel developers can see how the kernel is used and where there might be problems with the current kernel interface and design (good for Linux) - kernel developers can enforce a certain minimal level of code quality or not allow hacks which would lead to serve security issues or incompatibilities (good for Linux) - it's much easier to make sure that different drivers/kernel modules don't conflict in subtle ways (good for both Linux and vendors) - customers buying the hardware often can use it from release date without needing custom kernels (good for everyone) - abandoned drivers/modules can be picked up and maintained by 3rd parties allowing longer usage of otherwise no longer supported hardware Lastly while companies like Intel do not own Linux they are some of the main contributors of financial resources often more then covering any additional costs caused by this (I mean for server hardware and more powerful embedding hardware Linux strongly dominates the marked and it's also one of the main markets for Intel, Amd, Nvidea and one of the main building blocks for companies like Google). Anyway this is good for everyone and in _total_ reduces the amount of work involved in making Linux work with all kinds of hardware.
eklitzke 4y ago
For the point about the Google firmware modules, the firmware directory you linked to is specifically for Chromebooks, which people do have, and the modules are useful if you want to run vanilla Linux with coreboot on this hardware. If the code for these modules was maintained out of tree it would be much harder to run a regular Linux distribution on the hardware as you'd have to go build a custom kernel rather than just reconfiguring and rebuilding the kernel your distro provides. Furthermore the whole point of modules on Linux is that you can completely disable them, or if they're built as modules they'll only be loaded if needed (in some cases this is done on-demand automatically if the relevant hardware is detected, in other cases it might be done via logic in your initrd).
yxhuvud 4y ago
Eh, because it is nice to be able to buy hardware on release day and actually have it work.
msla 4y ago
> Why do the kernel developers allow corporations to shove code into the tree for hardware nobody has? Google does this too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/google/Kconfig https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... To get the code ready for when the hardware is available. > I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem? A lot of companies and individuals can step up to maintain the code once it's there and working. If it's important, they will and they have. Only dead-dead systems like the 80386 get removed; or, in this case, vaporware that never materialized to begin with. Modules are bad because they're code that isn't subject to the same review as normal kernel code, may be closed-source or under some obnoxious license, and probably is going to be more difficult to install than just a kernel update. So we want it to be "everyone else's problem" because that means anyone else can step up if a company fires the people maintaining the code for hardware the kernel team still wants to support. With a module, it might be the case that the module only works on some range of kernels and is very difficult to replicate its functionality on more modern ones once the original company drops out. That's not a good position to be in if you rely on being able to run modern Linux on that hardware.
- deleted 4y ago
  [deleted]
steponlego 4y ago
Linux hasn't been a community project in decades. It's basically run by a consortium of the biggest Chinese and American companies. And especially since Linus went away for his vacation-style treatment a few years ago, it's been getting much much worse.

beebeepka 4y ago

In other intel news, Raja is no longer with them. Seems like he was forced out and some of the rumours about the bleak future of their consumer GPU business may turn out to be true

cbozeman 4y ago
Turns out the leadership of Intel is stupider than I thought. It's almost impossible to believe that they actually thought they'd be able to go up against two GPU makers each with 25+ years of experience. This was always going to be a long uphill battle. Always. I figured it would take at least 10 years for Intel to become competitive, but turns out they tucked tail and ran. Mediocre!
- gfv 4y ago
  Intel has been making GPUs since roughly 2002, 845 chipset series. (There were earlier ones, but I'm
  - userbinator 4y ago
    Intel740, 1998.
    - ChancyChance 4y ago
      I was on the team that wrote the DirectX 3 and 5 drivers for the 740 (I wrote the vxds in assembly using MASM 6.11). It wasn't a GPU in today's terms (huge parallel vector engines), it was just a basic 3d pipeline: triangle pipe (with Gouraud lighting, 1st version didn't even have phong/specular) followed by rasterizer, with a 2D engine. You sent it triangles with aRGB color, and it interpolated and rasterized them. Dat's it. Total dud compared to Voodoo 3DFx or ATI Rage3D. But when we integrated it into the 810 chipset it became the main reason why 3D gaming was held back for a decade: it was the top selling graphics engine but it sucked so every game dev had to design for the lowest common denominator. It was never intended to be good. But it sure did result in the promotion of a lot of engineers to principal. (raises hand)

neom 4y ago

Weird I was born in Thunder Bay, thought maybe they were opening a plant there that got cancelled. Wonder why they called it Thunder Bay Harbor, especially because Thunder Bay is a harbor town...

DeathArrow 4y ago

Thunder Bay went to play with Larabee between the stars.