We want you: Standalone device driver library project

[tretornesp]

[EDIT, last version 31/10/23] -> We have moved the repository to a github organization. The previous url is no longer valid (we won't do this again )

Hello there!

My good friend Konect and I have started a project to provide standalone implementations for the most
common device drivers out there. The idea is to make something anyone can embed into his kernel with minimal
effort and in less than an hour.

Example: ¿You want to give networking capabilities to your kernel? Fair enough, just give us a the RSDP address
and we will yield you a few function pointers to work (usually read, write, ioctl).

The library can operate in fully pci-managed mode (we parse ACPI and PCI for you) or in manual mode (you fill
a well documented structure and hit the road).

Currently we have the drivers for:

- AHCI (Sata and Satapi disks)
- Intel e1000 (networking)
- Serial devices

We are on our way to implement XHCI (USB)

This project has just started, so enrolling onto it is pretty straightforward as there is no
codebase to adhere.

Please check the Github repo or contact us through this post or: [url]mailto://[email protected][/url]

We will appreciate any kind of help. Device driver programming, architectural reviews, documentation, etc.

The project's url: https://github.com/Open-Driver-Interfac ... /0.1-ALPHA
How to run, quickstart guide: https://github.com/Open-Driver-Interfac ... ckstart.md

¡We'll be in touch!

[eekee]

Ah! A common driver proposal with code already! This idea comes up all the time, but you're well ahead of the pack in having some drivers written already. I'm only aware of 3 others like this, all of which are quite old, UDI EDI and CDI. The newest may be CDI, whose repository shows only 1 update in the last 5 years. Not that updates necessarily matter; CDI seems to have all the drivers for running under emulation and is used by at least 10 OSs. I imagine all these are 32-bit given their age; a 64-bit driver set would be nice.

https://wiki.osdev.org/Device_Managemen ... Interfaces

Note that your post is missing links. You don't link your Github repository, and your email address is not a URL. An email address needs to be prefixed with mailto: to make it a URL.

[tretornesp]

You're right, I did this post yesterday in a hurry. Let me fix it real quick!

Also, we have uploaded the first test environment (a cute small limine kernel) and
updated the documentation.

Best regards.

[BigBuda]

Somehow this reminds me of the now defunct OSKit (https://wiki.osdev.org/OSKit and https://www-old.cs.utah.edu/flux/oskit/).

[tretornesp]

I can see some similarities. Our aim is for simplicity in spite of completeness.

The problem with most of thoose libraries is that they are just too old. As most
osdev related content, in my opinion some fresh code will do no harm here, even
if it is just a PoC

We have updated our codebase, now:

- We have a full testing environment.
- We have a dummy standalone driver as a reference implementation.
- We have an almost working ahci driver.
- We have pci device autodiscovery.

Our driver catallog roadmap now includes:

- audio
hda
- bus
pci
ps2
usb
- comm
serial
- fs
ext2
fat32
- graphics
kterm
orb
- net
e1000
- storage
ahci
nvme
- time
hpet
rtc
- virtual
tty
- misc
smbios
acpi

All of theese but the ps2 and usb drivers we have already finished and working (just missing porting them to ODI,
if everything ends up as expected we will be able to port each one in a few hours).

We would love some contributors tough! If you are reading this and sounds interesting, please contact us through here, email or github (:

P.S. The code is not hard, there is no assembly, no virtual memory shenannigans nor complex optimizations, just
a few of linked lists. Hopping into the project is really easy and we can even talk through it via discord

[BigBuda]

How feasible would it be for you to import functionality, or even code, from OSKit in order to further extend your project?

I did browse your repo but I wasn't able to find some of the things you mentioned, like the E1000 driver. Maybe you haven't pushed it yet?

[tretornesp]

We havent looked into OSKit yet. If you find it worth it we may check it out and take inspiration / aim for some degree of compatibility. Our project may fit as a subset of it and not the opposite.

About the drivers: We started the project a couple of days ago (the day of my first post). So first we need to finish the core, device auto-discovery (maybe even hotplug and a simple vfs interface).

The driver implementations we will port come from both our OSes, they are mostly working implementations but we have to turn them from hobby things to production'ish grade.

Here are a few links to the implementations you are looking for:

https://github.com/TretornESP/bloodmoon ... rivers/tty
https://github.com/TretornESP/bloodmoon ... ers/serial
https://github.com/TretornESP/bloodmoon ... /disk/ahci
https://github.com/TretornESP/bloodmoon ... /net/e1000
https://github.com/TretornESP/bloodmoon ... neric/ext2

https://github.com/kot-org/Kot/tree/mai ... /audio/hda
https://github.com/kot-org/Kot/tree/mai ... /time/hpet
https://github.com/kot-org/Kot/tree/mai ... s/time/rtc
https://github.com/kot-org/Kot/tree/mai ... hics/kterm
https://github.com/kot-org/Kot/tree/mai ... aphics/orb
https://github.com/kot-org/Kot/tree/mai ... rs/bus/ps2

Once again, if you find this project interesting, we would love to have more contributors onboard, no matter the background (:

[BigBuda]

On my OS, what I was doing to abstract the devices was to create something comparable to a BIOS that the second stage boot loader would load before loading the kernel, and make all devices a responsibility of that "BIOS" instead of drivers managed by the kernel. Your project looks like a close cousin in that regard. It's not a bad approach IMO.

[IanSeyler]

I have an NVMe driver here: https://github.com/ReturnInfinity/BareM ... e/nvme.asm

I have drivers for AHCI and E1000 as well in x86-64 Assembly.

[BigBuda]

Maybe it's time we pool up to build a repository of community drivers and respective documentation on how to adapt them so that we all can benefit from them and give back.

[tretornesp]

Hello everyone.

A NVME driver would be a great addition. I will also check your e1000 implementation as mine lacks a few really important features.

BigBuda's idea is pretty cool, creating a layer that loads device drivers
enables almost 100% abstraction, which is really cool. A really interesting
thing is that a crossover between our implementations is possible: how?

Take a look at https://github.com/Open-Driver-Interface/odi-barebones
there we have a very raw kernel to test the library. With minor difficulties,
it could bootstrap a statically linked kernel elf while writing control functions
pointers to specific physical addresses behaving then as a memory-mapped
device. A con would be a lot of care should be taken in undoing all HW changes performed during the dd layer boot.

¿What do you guys think on this approach?

As he also said, I will check all the drivers posted in this thread and try to
integrate them into the project (given licenses are compatible)

As an status update, we have been focusing on defining both interfaces: user interface (kernel - odi) and developer interface (driver - odi). Our autoconfiguration layer is almost defined architectonically-wise and we still
expect to start introducing device drivers later this week.

Collaborations are still really appreciated

Have a great day!

[BigBuda]

BigBuda's idea is pretty cool, creating a layer that loads device drivers
enables almost 100% abstraction, which is really cool. A really interesting
thing is that a crossover between our implementations is possible: how?

Well, if the drivers were written with a very explicit framework like paradigm, it might be easy for anyone to adapt them.

[tretornesp]

30/10/2023 - We have our first driver working!

As promised, we will keep you updated through this post:

We have finished the core and we are on our way to port the drivers, the first example is this:



It may seem like little progress but the thing is: This is the entire code
required for reading an ATA hard drive:

Code: Select all

    
void * rsdp = get_rsdp_address(); //You may get this from limine or scanning.
odi_autoconf(rsdp); //Do everything for me
odi_list_devices(); //Show me what you have found

u8 buffer[512] = {0}; //Create a buffer for one sector
u64 size = odi_read("hd0", 0, 1, buffer); //hd0 is the name of your drive

We are managing transparently all the complexity, you basically just have to provide basic implementations for the dependencies by creating a file (deps.c) (we will provide default implementations for the most basic functions like strncmp in the near future).

Also our test environment is pretty much ready.

Link to first PRE-ALPHA version: https://github.com/Open-Driver-Interfac ... /0.1-ALPHA

We are still looking for contributors

[Alexey1994]

In my opinion, you are making a big mistake when you write blocking code like here https://github.com/Open-Driver-Interfac ... i_dd.c#L56. It is always more profitable to write non-blocking calls that poll the state. Even for single-core processors. Because reading from a failed disk can be interrupted at any time, for example, by a timeout. Moreover, the polling timeout can be increased linearly or exponentially, i.e. you will have maximum control with a non-blocking API.

[tretornesp]

You are actually right. This driver will support non-blocking calls in the near future.

I'm about to update the core to support that kind of functionality in the NIC driver. Then i'll add non-blocking rw operations to the ahci driver.

You sound knowledgeable, if you want to propose any upgrade to a driver in a PR, It would be greatly appreciated