OSDev.org https://forum.osdev.org/ |
|
We want you: Standalone device driver library project https://forum.osdev.org/viewtopic.php?f=2&t=56983 |
Page 1 of 2 |
Author: | tretornesp [ Tue Oct 17, 2023 6:49 am ] |
Post subject: | We want you: Standalone device driver library project |
[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: mailto://[email protected] We will appreciate any kind of help. Device driver programming, architectural reviews, documentation, etc. The project's url: https://github.com/Open-Driver-Interface/odi/tree/0.1-ALPHA How to run, quickstart guide: https://github.com/Open-Driver-Interface/odi/blob/0.1-ALPHA/docs/quickstart.md ¡We'll be in touch! |
Author: | eekee [ Wed Oct 18, 2023 1:52 am ] |
Post subject: | Re: We want you: Standalone device driver library project |
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. |
Author: | tretornesp [ Wed Oct 18, 2023 4:12 am ] |
Post subject: | Re: We want you: Standalone device driver library project |
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. |
Author: | BigBuda [ Wed Oct 18, 2023 5:02 pm ] |
Post subject: | Re: We want you: Standalone device driver library project |
Somehow this reminds me of the now defunct OSKit (https://wiki.osdev.org/OSKit and https://www-old.cs.utah.edu/flux/oskit/). |
Author: | tretornesp [ Thu Oct 19, 2023 5:45 am ] |
Post subject: | Re: We want you: Standalone device driver library project |
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 |
Author: | BigBuda [ Fri Oct 20, 2023 9:58 am ] |
Post subject: | Re: We want you: Standalone device driver library project |
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? |
Author: | tretornesp [ Fri Oct 20, 2023 10:59 am ] |
Post subject: | Re: We want you: Standalone device driver library project |
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 (: |
Author: | BigBuda [ Fri Oct 20, 2023 1:24 pm ] |
Post subject: | Re: We want you: Standalone device driver library project |
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. |
Author: | IanSeyler [ Sat Oct 21, 2023 6:33 pm ] |
Post subject: | Re: We want you: Standalone device driver library project |
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. |
Author: | BigBuda [ Sun Oct 22, 2023 5:34 am ] |
Post subject: | Re: We want you: Standalone device driver library project |
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. |
Author: | tretornesp [ Sun Oct 22, 2023 1:21 pm ] |
Post subject: | Re: We want you: Standalone device driver library project |
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! |
Author: | BigBuda [ Sun Oct 22, 2023 4:42 pm ] |
Post subject: | Re: We want you: Standalone device driver library project |
tretornesp wrote: 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. |
Author: | tretornesp [ Mon Oct 30, 2023 1:38 pm ] |
Post subject: | Re: We want you: Standalone device driver library project |
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: 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-Interface/odi/releases/tag/0.1-ALPHA We are still looking for contributors |
Author: | Alexey1994 [ Tue Oct 31, 2023 4:27 am ] |
Post subject: | Re: We want you: Standalone device driver library project |
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. |
Author: | tretornesp [ Tue Oct 31, 2023 9:59 am ] |
Post subject: | Re: We want you: Standalone device driver library project |
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 |
Page 1 of 2 | All times are UTC - 6 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |