OSDev.org

NickJohnson wrote:I'm planning to write a wrapper that uses Linux modules as microkernel-style drivers to get obscure hardware working. That makes the whole kernel hurdle a million times smaller.

This sounds like a great idea, albeit perhaps quite a challenge. I wonder however, could such a wrapper be able to use non-opensource drivers e.g. the graphics driver from nVidia?

Aurdal wrote:

NickJohnson wrote:I'm planning to write a wrapper that uses Linux modules as microkernel-style drivers to get obscure hardware working. That makes the whole kernel hurdle a million times smaller.

This sounds like a great idea, albeit perhaps quite a challenge. I wonder however, could such a wrapper be able to use non-opensource drivers e.g. the graphics driver from nVidia?

That's the only way to go, or otherwise we could spend too much time just trying to write drivers for new hardware. That would be the next best thing to a 100% standard-hardware PC.

earlz wrote:

Edit: Also, I'm not too worried about driver development, because I'm planning to write a wrapper that uses Linux modules as microkernel-style drivers to get obscure hardware working. That makes the whole kernel hurdle a million times smaller.

Wow...that's possibly the greatest idea I've ever heard... course, I bet this is a bit harder than it sounds lol

The list of kernel API functions may be long, but 80% of them are things that are found in or can be adapted to a standard C library, and not everything has to be implemented. The gain of Linux's zillion-driver codebase would even outweigh rewriting the wrapper for every minor release (heck, even for every f'ing time Linus does a commit to master!).

All that's required is a module loader and a table of system functions identical to Linux that emulates enough functionality. That should work with any compliant Linux module, even proprietary ones.

The design of my driver interfaces makes this much easier. Drivers on my system, although user processes, can still access I/O ports freely, so that won't be a problem. And my system allows all user processes to handle their own page faults, so driver code trying to access memory mapped stuff at 0xFxxxxxxx could be catered to gracefully by the Linux wrapper.

Not to mention that it quite nicely encapsulates the virality of the GPL, and keeps it away from my nice ISC licensed kernel.

My base system is built in a very modular fashion, with almost every driver, server, or tool backed by at least one library that implements its actual functionality. If I get this working, I'll make sure to make its library as portable as possible, if anyone else would like to use it. Don't hold your breath though - it may be a while before I can even start.

You are aware that the Linux kernel maintainers have no intention of keeping the kernel/driver interface stable?

You will also have to have a very close eye on the licensing issue.

Solar wrote:You are aware that the Linux kernel maintainers have no intention of keeping the kernel/driver interface stable?

But even if you just restrict yourself to one specific Linux version (and it's internal interfaces), and the drivers compatible with it, you end up with more drivers than you could ever write alone. And the interfaces don't change so rapidly that it would be impossible to modify the wrapper once in a while. It's kind of sad that so much good driver code is bound up tightly (by interface, not just license) to only one system, even if that system is very open.

Solar wrote:You will also have to have a very close eye on the licensing issue.

I don't think there's that much to it if the drivers all run in userspace. The only piece that potentially needs to be (L)GPLed is the wrapper library that interfaces with the driver code. Plus, the driver code wouldn't even be in my system's source tree - the user has to compile modules from a Linux source tree and then load them into the wrapper, and the GPL puts very few (if any) restrictions on things that happen without distribution.

NickJohnson wrote:

Solar wrote:You are aware that the Linux kernel maintainers have no intention of keeping the kernel/driver interface stable?

But even if you just restrict yourself to one specific Linux version (and it's internal interfaces), and the drivers compatible with it, you end up with more drivers than you could ever write alone. And the interfaces don't change so rapidly that it would be impossible to modify the wrapper once in a while. It's kind of sad that so much good driver code is bound up tightly (by interface, not just license) to only one system, even if that system is very open.

If I implement another driver interface for my OS, it will probably be WDM/WDF. They're stable interfaces and every device a user might want to use has a Windows driver. The interfaces are probably quite nasty, but my OS will get more out of it. Performance might suck, but most devices that don't conform to a standard aren't essential system devices that have to be really fast. I don't really care if my TV tuner card driver isn't as fast as it could be. I do care if it doesn't work at all.

That is a good point - the only system with more drivers than Linux is Windows. But at least one issue for me is that my system is ELF based, and much more similar to Linux than Windows in architecture. As far as I can tell from the public WDM docs (which are 7 years out of date, btw), drivers need access to things like the registry, which would be hard to emulate.

Ndiswrapper lets you at least use all of the networking devices Windows supports, and would be easier to port than to completely duplicate. It could also be potentially extended to some other types of drivers. Networking, sound and graphics are the really tricky devices - everything else (essentially just storage of different types) is simple and important enough to be written natively.

Also, judging by how easy and consistent driver installation is on Windows, I would rather use a WDM wrapper as a very last resort. Third party drivers are rarely very good. I'd much rather use Linux (or maybe *BSD - their driver interface is *much* more stable, and there are no licensing issues) drivers, which are developed together with the system and updated frequently.

Maybe these last half-dozen posts should be moved to a different thread - they're *way* OT.

OpenSolaris has a very stable driver interface. Even the binary interface is fixed. Better implement a wrapper for that.