8 ms·

I agree, it's odd. I don't have anything recent, but back in 2004, the majority of the Linux kernel code was in its drivers: https://dwheeler.com/essays/linux-

I agree, it's odd. I don't have anything recent, but back in 2004, the majority of the Linux kernel code was in its drivers: https://dwheeler.com/essays/linux-kernel-cost.html https://dwheeler.com/essays/linux-kernel-cost.html I expect that most of the current Linux kernel code is also for handling hardware (that is, drivers + the code to handle various architectures).

emmericp 3y ago
66% was drivers in 2019.
AdmiralAsshat 3y ago
Could one not make the case that maybe device driver support doesn't belong in the kernel itself?
- boricj 3y ago
  NetBSD has architectured their drivers to be basically static archives reusable anywhere. It's part of the NetBSD rump kernel.
  - rjsw 3y ago
    The drivers are not used in that way in NetBSD, they are either compiled into the kernel or built as modules just like in Linux, the graphics drivers even use the source code from Linux.
  - einpoklum 3y ago
    What do you mean by "reusable everywhere"? I mean, where could they be used other than in a NetBSD kernel?
    - boricj 3y ago
      Anywhere. There are lots of examples on the topic ; running NetBSD driver code inside NetBSD's user-land is the simplest use-case (https://www.netbsd.org/docs/rump/sptut.html https://www.netbsd.org/docs/rump/sptut.html), but that code is portable without modifications to just about any context possible. Check out Antti Kantee's The Design and Implementation of the Anykernel and Rump Kernels if you want details on the architecture.
    - joveian 3y ago
      GNU Hurd for example. I haven't used it so I'm not sure of the exact status but it sounds like they are using it in some cases to make use of existing drivers in a microkernel style. There have been a few attempts to rumpify Linux but it doesn't seem like any of them succeeded and I'm not sure if anyone is still trying.
- heavyset_go 3y ago
  The Linux kernel driver API/ABI isn't stable so there's no permanent/versioned interface you can program against that would make out-of-tree drivers non-headache inducing: https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-... > You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.
  - quickthrower2 3y ago
    This is a great Conway's-law-busting approach. Just because the driver creator is a different human/org to the Kernel maintainers, doesn't mean their code needs to be separate if it makes more practical sense to bundle it all together. Also the "proof of work" of being allowed to add your driver is probably that you are designing and producing actual hardware, so it is hard to troll.
    - rcxdude 3y ago
      It just produces Conway's law in the other direction (which is smart). Now anyone wanting to use Linux effectively needs to integrate with its development process, which is large part of why it is successful as a project. (However, GNU attempted similar with their lack of an extension interface for GCC and that arguably blew up in their face with LLVM, so it's far from a guaranteed success)
  - meeho 3y ago
    Well windows pulled it off
- pjmlp 3y ago
  Yes, that is how it works in most sane operating systems, even more so nowadays where writing userspace drivers is preferable to dynamically loadable modules.
- ye-olde-sysrq 3y ago
  Isn't this this mono vs micro kernel debate all over again?
  - ssrc 3y ago
    I think it's monorepo vs multi-repo, and since Linux maintainers update the drivers (I believe) when internal APIs change, and the internal APIs are not stable, monorepo seems more practical.
    - davidw 3y ago
      There's something clever to say about the author of Linux vs the author of Git, but it's not coming to mind right now...
      - CRConrad 3y ago
        Both exactly equally famous for sometimes being an asshole?
    - actionfromafar 3y ago
      Maybe I’m missing the joke, but in or out of kernel context is orthogonal to how the source code is stored.
      - jonhohle 3y ago
        The author is the same (Linus), so it makes sense that he would design a source control system that supported the monorepo he created over the prior 15-ish years.
        midoridensha 3y ago
        Sure, but git does support multiple repos quite easily, and has support for submodules. It's grown a lot since when Linus first designed it.
      - 3y ago

emmericp 3y ago

66% was drivers in 2019.

AdmiralAsshat 3y ago

Could one not make the case that maybe device driver support doesn't belong in the kernel itself?

boricj 3y ago
NetBSD has architectured their drivers to be basically static archives reusable anywhere. It's part of the NetBSD rump kernel.
- rjsw 3y ago
  The drivers are not used in that way in NetBSD, they are either compiled into the kernel or built as modules just like in Linux, the graphics drivers even use the source code from Linux.
- einpoklum 3y ago
  What do you mean by "reusable everywhere"? I mean, where could they be used other than in a NetBSD kernel?
  - boricj 3y ago
    Anywhere. There are lots of examples on the topic ; running NetBSD driver code inside NetBSD's user-land is the simplest use-case (https://www.netbsd.org/docs/rump/sptut.html https://www.netbsd.org/docs/rump/sptut.html), but that code is portable without modifications to just about any context possible. Check out Antti Kantee's The Design and Implementation of the Anykernel and Rump Kernels if you want details on the architecture.
  - joveian 3y ago
    GNU Hurd for example. I haven't used it so I'm not sure of the exact status but it sounds like they are using it in some cases to make use of existing drivers in a microkernel style. There have been a few attempts to rumpify Linux but it doesn't seem like any of them succeeded and I'm not sure if anyone is still trying.
heavyset_go 3y ago
The Linux kernel driver API/ABI isn't stable so there's no permanent/versioned interface you can program against that would make out-of-tree drivers non-headache inducing: https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-... > You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.
- quickthrower2 3y ago
  This is a great Conway's-law-busting approach. Just because the driver creator is a different human/org to the Kernel maintainers, doesn't mean their code needs to be separate if it makes more practical sense to bundle it all together. Also the "proof of work" of being allowed to add your driver is probably that you are designing and producing actual hardware, so it is hard to troll.
  - rcxdude 3y ago
    It just produces Conway's law in the other direction (which is smart). Now anyone wanting to use Linux effectively needs to integrate with its development process, which is large part of why it is successful as a project. (However, GNU attempted similar with their lack of an extension interface for GCC and that arguably blew up in their face with LLVM, so it's far from a guaranteed success)
- meeho 3y ago
  Well windows pulled it off
pjmlp 3y ago
Yes, that is how it works in most sane operating systems, even more so nowadays where writing userspace drivers is preferable to dynamically loadable modules.
ye-olde-sysrq 3y ago
Isn't this this mono vs micro kernel debate all over again?
- ssrc 3y ago
  I think it's monorepo vs multi-repo, and since Linux maintainers update the drivers (I believe) when internal APIs change, and the internal APIs are not stable, monorepo seems more practical.
  - davidw 3y ago
    There's something clever to say about the author of Linux vs the author of Git, but it's not coming to mind right now...
    - CRConrad 3y ago
      Both exactly equally famous for sometimes being an asshole?
  - actionfromafar 3y ago
    Maybe I’m missing the joke, but in or out of kernel context is orthogonal to how the source code is stored.
    - jonhohle 3y ago
      The author is the same (Linus), so it makes sense that he would design a source control system that supported the monorepo he created over the prior 15-ish years.
      - midoridensha 3y ago
        Sure, but git does support multiple repos quite easily, and has support for submodules. It's grown a lot since when Linus first designed it.
    - 3y ago