Non-mainstream OSes (Genode, BSD, Haiku, etc.) tend to have problems with drivers availability/support. Why don't they reuse Linux drivers? I would imagine they could provide some ABI compatibility layer, which would make reusing Linux drivers possible. Why don't they? If "it's too much work" — can you give an example? Especially given that I've seen some of them adopt NetBSD drivers infrastructure (a.k.a. "rump kernel" IIUC), e.g. Haiku, Genode to some extent. Why is Linux a worse choice here than NetBSD? I don't believe it would be licensing, as you should not be affected by GPL immediately, as long as you do not distribute the drivers with the OS (which could be decoupled I believe).

edit: Per Jörg W Mittag's awesome comment, my general intention behind the question extends full well to Windows drivers too — i.e., why don't OSes reuse Linux or Windows drivers [by providing an ABI compatibility layer]?

  • 4
    The GPL seems to be quite relevant here. If you have a question on whether the GPL can be circumvented by distributing plugins/drivers separately, consider asking on Open Source. Consider also that Linux does not have stable internal APIs, and that drivers are maintained as part of the kernel source tree.
    – amon
    Oct 13, 2018 at 6:48
  • 1
    BSD isn't mainstream? That's news to an awful lot of internet traffic.
    – Rob
    Oct 13, 2018 at 12:41
  • @Rob Sorry for any & all errors/failures/imprecisions; I tried to focus on conciseness first... would you have some good suggestion how I could better rephrase this?
    – akavel
    Oct 16, 2018 at 12:02
  • @amon Would you mind converting this comment to a proper answer, to enable voting, editing, and further comments/discussion? Seems to me it's trying to be one, but somewhat shying away... sorry if I'm wrong/misguided! Thanks.
    – akavel
    Oct 16, 2018 at 12:07

1 Answer 1


The general answer is that adopting Linux kernel drivers (inside your other kernel) requires following Linux conventions, kernel ABI & API, architecture, and pre- and post- conditions. While the system call interface (see syscalls(2)) is stable and at least upward compatible (a user-land executable working on Linux 2.2 kernel should be runnable on Linux 4.18 kernel, at least when that executable is self-contained so statically linked), the Linux kernel interface is not that stable (so a kernel driver for Linux 2.2 won't even compile on Linux 4.18). Of course, there are also licensing considerations (not everyone wants to work with GPLv2 code).

This adoption of Linux drivers is not always possible, and might not even always be desirable. Look into the microkernel approach with drivers in user space (e.g. GNU Hurd). Look also into the unikernel way of thinking (e.g. MirageOS).

The (old, unmaintained) OSkit research project aimed to wrap Linux drivers for re-use by other kernels.

If you want to make your experimental operating system, you should look into OSDEV wiki. You might even want to make something with a design very different of the Unix (or Windows) way. Actually most OSes today (Linux, Unix, Windows, MacOSX, Android, VMS) have borrowed the ideas of Multics. You could dare inventing something different. For example, you might not even have files but some other ways of persistence (like the experimental GrassHopper OS did). Be sure to read Operating Systems: Three Easy Pieces to understand the terminology of OSes.

You could also adopt the following approach: use (some almost unmodified) Linux kernel, and build everything else (in user space) in your own way (this is still extremely ambitious and will take you many years of work). FWIW, the Pliant system is going that route (and J.PItrat's CAIA system, which still requires a C compiler, etc...). You might then not even use a Linux libc but something else that you have written. Look for example into Bones, a Scheme compiler which runs just on the Linux kernel (without the libc).

You could in principle (with many years of work) make even your own display server (and design its protocol) similar in spirit to Xorg or Wayland and redesign from scratch your GUI above that.

If you are interested more in user interface and less in OS internals, you could work on your own desktop environment (with your own windows manager) on Linux. Then, you'll get a very different look and feel.

But don't forget a hard fact: a Linux distribution is today a very complex system (of more than ten billions lines of code). Your lifetime is not enough to reinvent that alone. And today's desktop or laptop hardware (and essential firmware, like UEFI) is much more complex than what it was when Linus started coding Linux (e.g. even your keyboard wants an USB subsystem).

My hope (but I am pessimistic) is that several academic research teams will today be allowed and funded to work on brand new operating systems ideas (and free software prototypes). This would require funding for more than three years. This sadly does not happen, at least not in Europe (e.g. H2020 research grants only last 3 years) and probably not in North America. Remember Brooks' law and his Mythical Man Month book (first written in 1975, still very actual)... So sadly, a new Linus (making from scratch a new OS) is improbable today, since systems software research is irrelevant (e.g. because a small academic team needs more than 5 years of funding to make an OS with new ideas: remember Brook's observation: "if one woman can make a baby in 9 months, 9 women cannot make a baby in 1 month").

  • 2
    +1 Brilliant analysis with lots of resources ! I'd suggest to add to the second paragraph an example of why reuse may be not desirable: most microkernels try to isolate drivers in the user space which requires some significant differences in the design.
    – Christophe
    Oct 13, 2018 at 8:00
  • 2
    Also, there is the rather simple objection, that if you were going through all the trouble to do this in the first place, then Windows would be a much more attractive target, because everybody and their dog has drivers for Windows. See ndiswrapper for an example, where this was actually done. Oct 15, 2018 at 7:09
  • OP asked about "Non-mainstream OSes", and I don't think that Windows fit into that category Oct 15, 2018 at 10:53
  • I think the original quote was actually Wernher Von Braun not Brooks, "Crash programs fail because they are based on the theory that, with nine women pregnant, you can get a baby in a month", but Brooks may well have paraphrased.
    – Dan Mills
    Oct 15, 2018 at 15:18
  • Thanks a lot! Didn't know about Linux kernel interface instability, also didn't think about possible paradigm mismatch for different OSes. As to microkernels, that's where I thought it would be easier to do (in userspace), no? OSKit(-ng), NDISwrapper/NDISulator (thanks @JörgWMittag!) seem to be highly interesting, as real projects which tried to actually do this kind of porting. Topic of grants seems mostly unrelated, but I believe MINIX 3 was at least partly funded by a grant?
    – akavel
    Oct 16, 2018 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.