4 ms·

Does the kernel ever remove support for devices or does this stuff just bloat up the codebase for eternity?

ed25519FUUU 6y ago
I was thinking the same thing. Is this actually “good” for Linux? This strikes more like a technical bar trick than an important part of the kernel, and another surface which can be attacked.
- philwelch 6y ago
  I'm not a kernel expert but this seems like something that would be ISA-specific. If you're running a Linux kernel on anything other than a 68k processor, this code won't even be there for the most part. And if you are running it on a 68k, odds are you're running it on an old Mac anyway.
  - yjftsjthsd-h 6y ago
    I doubt that it's per-ISA; it's probably by device or maybe bus/transport. That is, with the right adapter you should be able to plug an ADB keyboard into a normal x86 box and have it work, but Linux will only actually load a driver if 1. it's statically compiled in (rare unless you built your own kernel), 2. you explicitly load it (`modprobe foo`), or 3. you plug in a device that uses that driver. As a reference point, I know NetBSD explicitly decouples these things; if you plug a brand-new PCI device into any system with a PCI slot, NetBSD doesn't care that you're plugging ex. a Sun keyboard into a "PC" USB card in a PowerPC mac - it has a keyboard driver, a USB driver, a PCI driver, and all of them use the same internal interfaces regardless of where they originated. I assume Linux does it the same way, but I don't know explicitly.
    - philwelch 6y ago
      The driver code seems to be under “macintosh/via-macii”, for whatever that’s worth.
  - throwaway373438 6y ago
    That's more or less correct. The relevant Kconfig is: if MACINTOSH_DRIVERS config ADB bool "Apple Desktop Bus (ADB) support" depends on MAC || (PPC_PMAC && PPC32) help Apple Desktop Bus (ADB) support is for support of devices which are connected to an ADB port. ADB devices tend to have 4 pins. If you have an Apple Macintosh prior to the iMac, an iBook or PowerBook, or a "Blue and White G3", you probably want to say Y here. Otherwise say N. In other words, the code is only built into the kernel on architectures where it is useful.
sahil-kang 6y ago
Yes, the kernel does remove unmaintained/unused code according to GKH at 30:30 in this interview [1]. [1] https://youtube.com/watch?t=1830&v=t9MjGziRw-c https://youtube.com/watch?t=1830&v=t9MjGziRw-c
beamatronic 6y ago
FireWire support was not present in kernel last time I tried it on CentOS
- duskwuff 6y ago
  Hasn't gone anywhere. Your kernel might not have support for it, but that doesn't mean it doesn't exist. https://github.com/torvalds/linux/tree/master/drivers/firewire https://github.com/torvalds/linux/tree/master/drivers/firewi...
  - beamatronic 6y ago
    It did go somewhere. It went out. Out of the kernel.
    - cbmuser 6y ago
      I mean, it's not like the previous comment proved you otherwise by posting a link to the current kernel git tree. But ok.
    - wtallis 6y ago
      There's a big difference between a driver being dropped from the upstream kernel source tree, and a driver module not being compiled and shipped by default by RedHat.
    - messe 6y ago
      You realise the kernel can be configured to support different hardware and many drivers are built as modules nowadays?
ploxiln 6y ago
Yes, linux removes support for stuff over time. But most drivers for old simple peripherals are considered not a problem - as long as they are clean optional components of their respective subsystems, they don't bother anyone. One example of support being removed includes old intel 386 processors, due to multi-core support complications apparently: http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html (that left intel 486 and later still supported) A bit more recently, a bunch of obscure architectures were removed, mostly because the last compilers to support them are too old or buggy: https://lwn.net/Articles/748074/ https://lwn.net/Articles/748074/ (Linux is in general really great about supporting a range of gcc/binutils versions going back about 7 years ... compare to some other popular projects these days which require a Go or Rust toolchain from just a few months ago.) And occasionally a driver is moved to "staging" to see if anyone complains, before being removed, because it is being a bother and no one seems to be maintaining it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea2e813e8cc3492c951b9895724fd47187e04a6f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... This is related to why "upstreaming" a driver can be very different from just releasing the source. Making a driver acceptable for merging into the mainline kernel, means making it clean enough that maintenance costs will be extremely low, for the next 5 to 10 years, even as the linux kernel sustains a surprisingly large amount of change in every single 3 month release cycle.
- stinos 6y ago
  they don't bother anyone Well, it's been like 2 decades since I last compiled a kernel myself, but back then I was definitely bothered with the pages of obsolete hardware which could be selected from when running make menuconfig. Not sure if/how people configure kernels these days but I assume it didn't get better?
  - cbmuser 6y ago
    What's wrong with the kernel supporting a wide variety of hardware? As long as the stuff is actively maintained, I don't see a problem as this means it's actually being used. Linux always has had a very wide hardware support and if you are bothered about that, you can either use the make target "localmodconfig" or just don't build your kernels yourself.
cbmuser 6y ago
> Does the kernel ever remove support for devices or does this stuff just bloat up the codebase for eternity? As long as there is an active maintainer for the code, the code can stay forever and it's not really bloating up the kernel due to the modular nature of it.
tenebrisalietum 6y ago
There was a time when device support in a Unix meant being literally built into the kernel. Then modules became a thing. Linux has thousands of modules representing device drivers, iptables targets, crypto processing, and others. So while the codebase may become larger with the additional devices supported, this doesn't have to impact your running kernel at all. Modules that represent hardware not installed on your system aren't typically loaded and therefore don't occupy RAM. You can also blacklist modules, in the event something's loading where it shouldn't and you don't want it in RAM. That being said you can do an `lsmod` and look at the modules actually loaded. If some are there that represent things you'll never use (like QNX partition support), blacklisting them may save you some KBs of RAM and lower your kernel's attack surface. QEMU's floppy disk hardware support was impacted by a security vulnerability not too long ago, and I've had the `floppy` module blacklisted for a long time on my VMs. If you are running Linux on a purely static system that won't change hardware over its life (including things like USB devices), you can then compile a kernel with all modules "built-in" and disable module loading entirely.

I was thinking the same thing. Is this actually “good” for Linux? This strikes more like a technical bar trick than an important part of the kernel, and another surface which can be attacked.

philwelch 6y ago
I'm not a kernel expert but this seems like something that would be ISA-specific. If you're running a Linux kernel on anything other than a 68k processor, this code won't even be there for the most part. And if you are running it on a 68k, odds are you're running it on an old Mac anyway.
- yjftsjthsd-h 6y ago
  I doubt that it's per-ISA; it's probably by device or maybe bus/transport. That is, with the right adapter you should be able to plug an ADB keyboard into a normal x86 box and have it work, but Linux will only actually load a driver if 1. it's statically compiled in (rare unless you built your own kernel), 2. you explicitly load it (`modprobe foo`), or 3. you plug in a device that uses that driver. As a reference point, I know NetBSD explicitly decouples these things; if you plug a brand-new PCI device into any system with a PCI slot, NetBSD doesn't care that you're plugging ex. a Sun keyboard into a "PC" USB card in a PowerPC mac - it has a keyboard driver, a USB driver, a PCI driver, and all of them use the same internal interfaces regardless of where they originated. I assume Linux does it the same way, but I don't know explicitly.
  - philwelch 6y ago
    The driver code seems to be under “macintosh/via-macii”, for whatever that’s worth.
- throwaway373438 6y ago
  That's more or less correct. The relevant Kconfig is: if MACINTOSH_DRIVERS config ADB bool "Apple Desktop Bus (ADB) support" depends on MAC || (PPC_PMAC && PPC32) help Apple Desktop Bus (ADB) support is for support of devices which are connected to an ADB port. ADB devices tend to have 4 pins. If you have an Apple Macintosh prior to the iMac, an iBook or PowerBook, or a "Blue and White G3", you probably want to say Y here. Otherwise say N. In other words, the code is only built into the kernel on architectures where it is useful.

sahil-kang 6y ago

Yes, the kernel does remove unmaintained/unused code according to GKH at 30:30 in this interview [1]. [1] https://youtube.com/watch?t=1830&v=t9MjGziRw-c https://youtube.com/watch?t=1830&v=t9MjGziRw-c

beamatronic 6y ago

FireWire support was not present in kernel last time I tried it on CentOS

duskwuff 6y ago
Hasn't gone anywhere. Your kernel might not have support for it, but that doesn't mean it doesn't exist. https://github.com/torvalds/linux/tree/master/drivers/firewire https://github.com/torvalds/linux/tree/master/drivers/firewi...
- beamatronic 6y ago
  It did go somewhere. It went out. Out of the kernel.
  - cbmuser 6y ago
    I mean, it's not like the previous comment proved you otherwise by posting a link to the current kernel git tree. But ok.
  - wtallis 6y ago
    There's a big difference between a driver being dropped from the upstream kernel source tree, and a driver module not being compiled and shipped by default by RedHat.
  - messe 6y ago
    You realise the kernel can be configured to support different hardware and many drivers are built as modules nowadays?

ploxiln 6y ago

Yes, linux removes support for stuff over time. But most drivers for old simple peripherals are considered not a problem - as long as they are clean optional components of their respective subsystems, they don't bother anyone. One example of support being removed includes old intel 386 processors, due to multi-core support complications apparently: http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html (that left intel 486 and later still supported) A bit more recently, a bunch of obscure architectures were removed, mostly because the last compilers to support them are too old or buggy: https://lwn.net/Articles/748074/ https://lwn.net/Articles/748074/ (Linux is in general really great about supporting a range of gcc/binutils versions going back about 7 years ... compare to some other popular projects these days which require a Go or Rust toolchain from just a few months ago.) And occasionally a driver is moved to "staging" to see if anyone complains, before being removed, because it is being a bother and no one seems to be maintaining it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea2e813e8cc3492c951b9895724fd47187e04a6f https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... This is related to why "upstreaming" a driver can be very different from just releasing the source. Making a driver acceptable for merging into the mainline kernel, means making it clean enough that maintenance costs will be extremely low, for the next 5 to 10 years, even as the linux kernel sustains a surprisingly large amount of change in every single 3 month release cycle.

stinos 6y ago
they don't bother anyone Well, it's been like 2 decades since I last compiled a kernel myself, but back then I was definitely bothered with the pages of obsolete hardware which could be selected from when running make menuconfig. Not sure if/how people configure kernels these days but I assume it didn't get better?
- cbmuser 6y ago
  What's wrong with the kernel supporting a wide variety of hardware? As long as the stuff is actively maintained, I don't see a problem as this means it's actually being used. Linux always has had a very wide hardware support and if you are bothered about that, you can either use the make target "localmodconfig" or just don't build your kernels yourself.

cbmuser 6y ago

> Does the kernel ever remove support for devices or does this stuff just bloat up the codebase for eternity? As long as there is an active maintainer for the code, the code can stay forever and it's not really bloating up the kernel due to the modular nature of it.

tenebrisalietum 6y ago

There was a time when device support in a Unix meant being literally built into the kernel. Then modules became a thing. Linux has thousands of modules representing device drivers, iptables targets, crypto processing, and others. So while the codebase may become larger with the additional devices supported, this doesn't have to impact your running kernel at all. Modules that represent hardware not installed on your system aren't typically loaded and therefore don't occupy RAM. You can also blacklist modules, in the event something's loading where it shouldn't and you don't want it in RAM. That being said you can do an `lsmod` and look at the modules actually loaded. If some are there that represent things you'll never use (like QNX partition support), blacklisting them may save you some KBs of RAM and lower your kernel's attack surface. QEMU's floppy disk hardware support was impacted by a security vulnerability not too long ago, and I've had the `floppy` module blacklisted for a long time on my VMs. If you are running Linux on a purely static system that won't change hardware over its life (including things like USB devices), you can then compile a kernel with all modules "built-in" and disable module loading entirely.