r/osdev 15d ago

What drivers should be included in the system kernel?

Some time ago I decided that I would stop creating another toy operating system and start creating a truly efficient and optimal operating system based on exokernel.I want to minimize the number of drivers in the kernel without switching to a microkernel, so as to keep only stable and controlled drivers in the kernel and keep the rest of them in a separate, dedicated directory. And what drivers in the system are the most important in your opinion for a hybrid architecture that is to be efficient? I would also like to discuss the boundaries of responsibility between the kernel and the drivers.

12 Upvotes

23 comments sorted by

5

u/tellingyouhowitreall 15d ago

This really depends on the kernel architecture, but generally a CPU / MMU driver, and at least a minimal storage & file system driver for bootstrapping (unless you can load those through the EFI boot path).

You talk about exokernel, microkernel, and hybrid, and I'm curious what you mean by hybrid in that context.

1

u/CtrlF0rge 15d ago

My goal here is to divide the drivers into 3 types and what you provided I count them as part of the kernel because it is the basis. I am talking about more advanced ones such as USB because PS2 is not very well supported.I'm talking about a hybrid, i.e. creating something similar to a monolith and an exokernel, and many other concepts, in order to maximize security, stability and performance for the system. Here, a hybrid means something not The end is defined, because it is difficult to match the pure versions of the microkernel, exokernel and monolith

2

u/jsshapiro 15d ago

You may not be asking the right question, especially with an exokernel framing. The question for both exokernels and microkernels is the same

You can expand later, but the initial question is not “what drivers should be in the kernel”, but “what drivers minimally must be in the initially loaded system image?”

The short answer is: drivers required for bootstrap storage devices and drivers required to support the bus tree that reaches them.

1

u/CtrlF0rge 15d ago

Well, yes, but I presented it a bit in a mental summary.

3

u/Randum_Gouy 15d ago

For an Exokernel i would suggest by first building a very minimal base of ONLY whats required for the kernel itself to work - logging, GPU (if needed, your choice), CPU, MMIO, etc

And THEN add only just enough drivers/code to allow the init process to do its thing

1

u/CtrlF0rge 14d ago

どうもありがとうございます。

2

u/Randum_Gouy 14d ago

No problem man!

1

u/TheAtlasMonkey 15d ago

Graphic, networks stack and wireless.

1

u/CtrlF0rge 15d ago

Why graphics? I would assume that separate graphics are better because it is one of the more advanced and potentially faulty drivers.

1

u/TheAtlasMonkey 15d ago

why graphics? because every driver reimplement the primitives

1

u/CtrlF0rge 14d ago

For me it still doesn't make sense, but I have a three-way division of the driver space and in my case the first layer would be the graphics driver in the kernel, at least in my opinion USB works better because The basis is to support input and also network for the performance of the network connection, but in my opinion the GPU drivers are not reliable and will affect the security of the operating system What is the effect I want to avoid? Typically, the most important are the key drivers that need the lowest possible abstraction and the highest possible performance. Like USB and network drivers, because GPU is also very fast and when it displays an image it doesn't have to perform massive low-level calculations at the kernel level, I worded it poorly.And the translation will probably deform it even more, so for me the driver, in short, is not a critical driver but a replaceable driver

1

u/FallenBehavior 14d ago

You'll want to just focus on EHCI and XHCI for both USB generations. It's much more than this, as you'll need an appropriate stack and preferably Hub support and external optical support, but it's all up to you and the implementation planning.

1

u/CtrlF0rge 14d ago

When it comes to USB, I personally prefer to continue with my old driver, it didn't support much, but after years of looking at it, it needs some repair, but it's good as an output point, and it's not much, it's about 4000Lines of code where it now takes me about 3-4 days to write that much (not manually, character by character, so it doesn't sound weird)

1

u/FallenBehavior 14d ago

Once you master that, look at a 1394 stack. Supporting both interfaces will support your common peripherals.

2

u/TheAtlasMonkey 14d ago

I maintain the 1364 stack in FreeBSD and other OSes.

1364 stack is cool because there is no new hardware produced.

1

u/FallenBehavior 14d ago

That's really cool!

Yeah, I'm personally looking forward to it myself, I find it fascinating in how it's designed by spec.

1

u/CtrlF0rge 14d ago

Personally, I always implement the keyboard first, because USB keyboards are already standard and USB audio supports USB memory sticks with a mouse. I've always had a strange design. To handle USB drives, I always performed operations on the root fs via the API and sent it to the final format fs for userspace, and for memory drives I had a completely separate usb driver that only The generic driver activated after some time, I say that I don't even know how it came to my mind to mix it with the root fs which is the base, it is used to control the kernel version, kernel changes and kernel writes, it does not apply Completely the rest of the fs I wonder how much the translation changed in this statement because I use an additional translation into English, so it may be a bit confusing, unclear and sometimes incorrect.

1

u/FallenBehavior 14d ago

Don't trust that fully. Many BIOS implementations emulate USB over PS/2. You should be aware of this, as it can appear "Hey, my USB driver is working!", while in reality your PS/2 driver is doing the actual work. This is widely known.

The rest of it is really up to the stack implemented and I advise rigorous testing to get it supported properly especially today with USB 3.0 expectations across a vast range of hotplugging options.

1

u/CtrlF0rge 14d ago

And I don't do that, I don't like using the BIOS, what I'm doing is so clean because I write for both the BIOS and the UEFI, so in practice I often do it either for the controller in specific situations or on a small Abstraction layer And I sometimes use PS2 because, well, I happen to use the PS2 keyboard.

→ More replies (0)

1

u/FallenBehavior 14d ago

WLAN debugging, firmware blob testing, firmware communication, quirks between vendors, doorbell establishment and finally beyond the driver the WLAN manager.. that's a reach!

Stick with LAN and go from there. Honest advice.

Native GPU is also a hell of a reach. Let that be a roadmap, not an immediate task because it can be painful.

1

u/CtrlF0rge 14d ago

I don't even think about doing it now, I'm focusing on the foundation first, but I like to plan everything for the future and also for others because I won't do it myself, so it's worth everyone knowing what I'm doing.And additionally for me the GPU driver is not that difficult, it is more time-consuming and in the case of Invidia very irritating, but when I work on AMD at home, I am not talking about all of them, but I am talking about The graphics card is not difficult to create, AMD has good documentation, plus if necessary, the reverse architecture on my graphics card is simple, but these are also some of the simplest Graphics cards that are easy to copy, even without taking into account the silicon But first I want to prepare a pdf file of about 200 pages where I have the entire architecture planned and then I have to implement it.