Hacker News Reader

Comment by Polylactic_acid | Hacker News Reader

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

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 (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/ (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/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.

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?

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.

What's wrong with the kernel supporting a wide variety of hardware?

I think you misunderstood my reply. I'm not saying the kernel should drop support, I'm merely replying to the 'doesn't bother anyone' with a practical example of why it might bother someone on a particular level.

It bothers you that the kernel supports hardware you don't have?

There was a time back in the 90s where one could go through every option in the Linux kernel config, and through every package in the dselect list (does anyone here still remember dselect?), and know what each one was for, and whether it should be selected or not. Nowadays, there are too many options for that (and for dselect, too many packages).

Again, no, that is not what bothers me. I'm not sure if I was really that unclear - twice - or if it's just because it's monday :)

So here it goes, in full (similar to sibling poster cesarb's story): once you could, spending some time, just go over pretty much every possible option and select what you needed. Which mattered back then (at least to me), because compilation already took half a day on my machine so the less things to compile the better. Now over the years came more and more support for different hardware. That fact by itself obviously did not bother me, also because it meant I could finally hook up my insert not too common device here. What started to bother me was just that it took more time to go over all options. Whishful thinking because hard to implement, but I would have liked a flag like "ok you can just skip everything for harware which only existed before 1995 because I don't have that". So, reflecting on that period, I'm simply wondering what it must be like today to go through all options. I.e. I wonder if others might be bothered by the sheer amount of options out there.

No, there are probably more kernel config options than ever ... but they are decently well organized in a tree. I always start with my linux distro's stock kernel config, and then go through and find stuff to add and remove which is familiar enough to me, leaving the majority as-is. There is search, there are other ways to get a good starter config, I'm no expert ...

> 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

7 years old gcc was released back in 2013, or 36 years after gcc's initial release

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

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.

> 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.

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

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/firewi...

It did go somewhere. It went out. Out of the kernel.

I mean, it's not like the previous comment proved you otherwise by posting a link to the current kernel git tree.

But ok.

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.

You realise the kernel can be configured to support different hardware and many drivers are built as modules nowadays?

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.

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.

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.

The driver code seems to be under “macintosh/via-macii”, for whatever that’s worth.

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.

Reply on news.ycombinator.com