Porting Linux Drivers to a custom OS

[taifunbrowser]

Has anyone had any luck porting linux drivers directly to their operating system?

I find that looking at the linux driver repository is not entirely helpful for developing drivers. However, the ability to drag and drop drivers from the linux source into a custom OS would give a lot of power to custom OS's.

It appears that most drivers are self contained, except for their use of: (I refer to linux's source code in the following, having mostly analyzed sound drivers)
- the /sound folder (spec. for sound drivers)
- mutexes, semaphores
- DMA operations
- requesting IRQ lines and inb / outb ports

and then sometimes (they shouldn't really though...) the lib/string and stdio functions. It should be possible to implement these features in a custom OS and fool drivers into believing they are running on linux. Long story short, is there anything obviously impossible with this approach for driver porting?

[Solar]

Take note that the Linux maintainers have no intention of keeping the kernel - driver interface stable.

The relevant paper is called Stable API Nonsense and is part of every Linux distribution (/usr/src/linux/Documentation/stable_api_nonsense.txt).

[gerryg400]

Quote from that paper ...

Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech .)

That just about sums up why I don't like the GPL.

[b.zaar]

Change the original question to using FreeBSD or maybe ReactOS drivers, would it be difficult to use these drivers wrapped up in a native driver on your own system?

[Brendan]

Hi,

It appears that most drivers are self contained, except for their use of: (I refer to linux's source code in the following, having mostly analyzed sound drivers)
- the /sound folder (spec. for sound drivers)
- mutexes, semaphores
- DMA operations
- requesting IRQ lines and inb / outb ports

For any device driver, there's (up to) 3 different interfaces:

• The interface used for low-level kernel functionality. This including things like memory management, scheduling, re-entrancy locking, IRQ handling, "module" file format and loading (and dynamic linking), etc.
• The interface used by higher levels. For an example, a storage device driver would have to provide some sort of interface that file systems use; an ethernet driver has to be compatible with the TCP/IP stack, etc. In your case this works in reverse - your file system/s would need to be compatible with the interfaces provided by Linux drivers, your networking would need to be compatible with the interfaces provided by Linux networking drivers, etc.
• The interface to the hardware. This depends on the device, and for some devices (e.g. PCI sound cards) it doesn't depend on anything else. However, for some types of device there is no direct hardware access and the driver has to communicate with its device via. a different driver. One example would be all drivers for USB devices (which talk to a "USB controller" driver to get anything done).

To run Linux drivers you need to implement all of these interfaces so that they work like they do in Linux; which mostly means that you're writing a Linux clone (with worse quality/reliability due to less maturity and less testing).

Then there's the whole "we're too stupid to design anything worth sticking with" mentality, and the constant need to rewrite stuff for the sake of changing from badly designed poo to "different" badly designed poo. Solar's comments about the stable driver interface are just the beginning - this mentality permeates the entire OS, from low level kernel interfaces up to the highest levels. Some parts of it (X, video drivers, mesa, etc) are like an old video of The Three Stooges - it'd be funny if it wasn't so important.

The "in-kernel USB interfaces" example in the Stable API Nonsense is a perfect example. To me, it sounds like someone (who probably only cared about one specific device at the time) decided that a synchronous interface (WTF?!?) would be "good enough for now" and implemented it, and some other moron accepted it into the kernel without thinking about it much. Later (after other developers wrote drivers that relied on the original interface without thinking about it) they realised it was never a good idea to begin with and tried to fix it (but were probably worried about breaking old code and didn't want to start from scratch with a proper design) so they hacked up yet another "good enough for now" solution. Eventually this "never designed properly from the start" interface proved to be bad enough to justify a re-re-write, so... Maybe after they've rewritten it 5 more times they might come close to what they could've started with if anyone bothered spending any time examining the requirements and coming up with a good design in the beginning.


Cheers,

Brendan

[casnix]

i personally intend to port the ext2fs driver from my suse 8.1 linux to my OS as I am currently to lazy to take the easy and write the driver for myself and avoid the possibility of running into an unfixable problem and ending up rewriting the whole thing myself.

Sooo.....that and (maybe) the USB driver. Other than that, my OS has a **** load of drivers for feature with binary, execution, CDSX language with the CDSX framework, and such. I'm not too sure how many drivers I would want to uave for devices. My OS is supposed to be bare frame type thing, no restrictions, infinite possibilities if you just right the right application

But yeah, fs and maybe printer drivers are the only things I would want to port, for now...

Good luck,
Matt

[gerryg400]

The Linux ext2 driver needs a vfs above it with dcache and inode cache, and a fully featured buffer cache below it. As Brendan pointed out (for Linux drivers in general), it also relies on the Linux internal APIs including those for memory management, kernel exception handling, kernel daemon support, scheduling, locking (spin and rw), sleeping, IO waiting, as well as those for general stuff for lists, trees, heaps, searching, sorting etc. You will need to reshape all that to fit in your OS.

Even compiling the Linux ext2 driver will require 100s of Linux header files. You will need to sort through those for the bits you need.

Also, there is reasonably good documentation showing how to implement an ext2 filesystem from several sources. I don't believe the documentation that explains how to implement the required Linux driver framework exists.

I estimate a reasonably good, hobby-standard, caching ext2 filesystem with a simple ata driver could be done in fewer than 2000 lines. I think building a framework to support the Linux ext2 driver would be a great deal more difficult than that.

[a1246279]

There is DDEKit. It basically reduces porting certain types (a growing set, currently only network I think) of Linux drivers to implementing some functions that are part of the DDE library specific to your OS. It is used by several L4 based projects and by Hurd on Mach.

[piranha]

Don't try to port in the ext2 driver from linux. Write it yourself. Not only will it help you learn how it works, you will be able to design your own interfaces that are much better suited to your OS. Also, it will be so much easier to write it yourself. I got a read-only ext2 driver in a couple hours last time I wrote one, and I wasn't even rushing it. If you really want to port an ext2 driver, try the CDI one. It's pretty easy to port (I did it for the hell of it) even if you don't support CDI and you change all the code to what you want.

Seriously, write your own. It will help you later when you need to add on the the ext2 driver, or are debugging.

-JL

[Bietje]

As mentioned above you learn allot more from writing things yourself. That doesn't mean you shouldn't look at the linux/bsd/reactOS/grub code at all. If you can't figure out something you could look at some working code which might push you in the right direction.