Device Driver Adaptation?

[leejbaxter]

Hi folks,

Firstly, please forgive me for any misunderstandings; I'm really new to the world of OS development, so it may seem like I'm asking obvious questions for the time being, but I can accept constructive criticism!

I'm currently dabbling with the idea of creating an OS from scratch, which will be 99.999999% automated (save diagnostic functions .etc.); here's where I've met a potential speed-bump! Obviously, when I create my OS, it won't have any device-specific drivers; this is going to be a big setback if I want my system to be fully-automated because I'll need to develop drivers for numerous devices, not to mention that this OS is planned to be run on almost any x86-based computer.

This is where I've had a lightning bolt! Windows and Linux automatically install drivers for common hardware, and there's masses of device drivers for these OSes. My question is, is it possible to develop a sort of 'adaptor' for Windows/Linux device drivers so that I can use them with my own OS? As far as I can see, it is theoretically possible (not that it would be a trivial task, by any means); what I'd be essentially doing is converting the interface for the drivers to suit my OS.

Could anybody give me advice on this, and if it isn't going to work, please could alternatives be suggested?

Thanks in advance, Lee.

[Xzyx987X]

Possible? Perhaps. ReactOS for instance, supports Windows drivers. Of course, it's basically a ground up reimplementation of Windows, and even then it's compatibility isn't perfect. Some hacky device drivers for instance, may use undocumented features, or even depend on specific memory structures being in a certain place in memory to work.

I think what you'll find though, is that most devices that are the highest priority for supporting, are based on open standards. And writing new drivers based on those standards, is in 99.999999% of cases the most practical approach. 3D graphics acceleration drivers are a bit problematic, mainly due to complete lack of standards or documentation, but people are working on it.

I'd like to know however, what exactly are you trying to do with this OS that couldn't be readily accomplished by hacking up an existing open source OS to suit your needs?

[Kevin]

It's possible to do this in theory, although it will probably require quite some work. You basically implement the driver API of the source OS. Examples that I know where such an approach was taken in practice are NDISwrapper (running Windows network/WLAN drivers on Linux) and WinKVM (a port of KVM virtualization code to Windows by emulating the Linux kernel API; this one is scary, but they say it works - even thoug slower than just emulating with qemu...)

If you decide that it's not the way to go, there are still CDI and UDI which try to provide a driver interface that allows driver to be shared between OSes. Both of them don't have as many drivers as Linux or Windows, so you'll still need to write some drivers, but you would get at least some drivers for free (for CDI; I'm not sure about the UDI status) and I think both projects would gladly accept contributions of new drivers.

[leejbaxter]

Possible? Perhaps. ReactOS for instance, supports Windows drivers. Of course, it's basically a ground up reimplementation of Windows, and even then it's compatibility isn't perfect. Some hacky device drivers for instance, may use undocumented features, or even depend on specific memory structures being in a certain place in memory to work.

I think what you'll find though, is that most devices that are the highest priority for supporting, are based on open standards. And writing new drivers based on those standards, is in 99.999999% of cases the most practical approach. 3D graphics acceleration drivers are a bit problematic, mainly due to complete lack of standards or documentation, but people are working on it.

I'd like to know however, what exactly are you trying to do with this OS that couldn't be readily accomplished by hacking up an existing open source OS to suit your needs?

Thanks for the quick reply!

What I'm attempting to do is to build an OS that runs fully automated (apart from the aforementioned diagnostics tools) so that it can intelligently control an x86-based computer system. The reason that I want to develop this as an OS from scratch is for the learning experience, so that I know every single aspect of the system's design (minus the adapted drivers, of course!), and so that only necessary subsystems/daemons are running. I'm expecting the project to take years to build, but I think that implementing it myself could save some headaches in the long run.

[gravaera]

Yo

...

Windows and Linux automatically install drivers for common hardware, and there's masses of device drivers for these OSes. My question is, is it possible to develop a sort of 'adaptor' for Windows/Linux device drivers so that I can use them with my own OS? As far as I can see, it is theoretically possible (not that it would be a trivial task, by any means);

Yes, this is completely possible, but it would still take a bit of work (a hefty amount); but the gains forecasted to come from doing it are several orders of magnitude above the pain for the labour

Basically, you need to find out two main things, and then several other sub-questions will stem from there: how do windows drivers du jour provide the NT kernel with a struct of entry points into themselves? In other words, where is the driver "information block" and how is is found within an NT driver, and how is it to be parsed?

Second, does NT use the stdcall convention for its drivers? This would require some stack transformation on calling in and returning. From there, you have the MSDN knowledgebase and their extensive articles which detail how to develop drivers for NT. You could choose to adopt some already-designed driver interface like the UDI, or the CDI, or design your own. In each case the process is the same: you write a wrapping layer with the same reasoning as the "NDIS Wrapper" project which allows users to use NT NIC drivers under Linux due to the fact that MS adopted NDIS, and NDIS is an open standard, so I imagine it wasn't that much work to reverse engineer with basic information from MSDN.

--Have fun,
gravaera

[Brendan]

Hi,

My question is, is it possible to develop a sort of 'adaptor' for Windows/Linux device drivers so that I can use them with my own OS? As far as I can see, it is theoretically possible (not that it would be a trivial task, by any means); what I'd be essentially doing is converting the interface for the drivers to suit my OS.

Essentially, what you'd be doing is modifying your OS to suit the interfaces needed for the device drivers.

For example, for Windows drivers you'd be supporting the PE file format, supporting DLLs, implementing any DLLs that drivers rely on, implementing a registry, implementing the "event log", implementing messaging, implementing the re-entrancy model (locks, etc) and emulating Windows virtual memory model. On top of that you'd be implementing most of the Windows API used by applications so that the device driver installers and utilities that come with the device drivers actually work (for a simple example, go to "control panel" and change your printer's configuration).

For example, for Linux drivers you'd be supporting the ELF file format, implementing the "/proc" filesystem and the "/dev" file system (and "udev"?) and the "/etc" directory for configuration files, implementing the "system log" stuff, implementing pipes, implementing the re-entrancy model (locks, etc) and emulating Linux virtual memory model. Then you'd be trying to find a way to install the device drivers (and maybe adopting GPL2) and fixing it each time the Linux kernel developers change anything.

My guess is that before you've got 10% of it done you'll go insane, and the police will find you unconscious and naked in a large shopping mall surrounded by spoiled pastries - maybe donuts, maybe some sort of bun containing sultanas or raisins, or maybe something French like croissants. Regardless of what sort of pastries it is, the nearest bakery will go bankrupt 6 months later because none of their customers will be able to go near their shop without being reminded of the great pastry massacre of 2011. You will be content (the medication the nurses make you take will make sure of that), until you convince the nice doctors to release you. Unfortunately you'll be hit by a truck on a busy highway soon after that (but don't blame the truck driver - there's no way he could've seen an old man kissing the white line in the middle of the road in time to avoid impact).


Cheers,

Brendan

[leejbaxter]

Hi,

My question is, is it possible to develop a sort of 'adaptor' for Windows/Linux device drivers so that I can use them with my own OS? As far as I can see, it is theoretically possible (not that it would be a trivial task, by any means); what I'd be essentially doing is converting the interface for the drivers to suit my OS.

Essentially, what you'd be doing is modifying your OS to suit the interfaces needed for the device drivers.

For example, for Windows drivers you'd be supporting the PE file format, supporting DLLs, implementing any DLLs that drivers rely on, implementing a registry, implementing the "event log", implementing messaging, implementing the re-entrancy model (locks, etc) and emulating Windows virtual memory model. On top of that you'd be implementing most of the Windows API used by applications so that the device driver installers and utilities that come with the device drivers actually work (for a simple example, go to "control panel" and change your printer's configuration).

For example, for Linux drivers you'd be supporting the ELF file format, implementing the "/proc" filesystem and the "/dev" file system (and "udev"?) and the "/etc" directory for configuration files, implementing the "system log" stuff, implementing pipes, implementing the re-entrancy model (locks, etc) and emulating Linux virtual memory model. Then you'd be trying to find a way to install the device drivers (and maybe adopting GPL2) and fixing it each time the Linux kernel developers change anything.

My guess is that before you've got 10% of it done you'll go insane, and the police will find you unconscious and naked in a large shopping mall surrounded by spoiled pastries - maybe donuts, maybe some sort of bun containing sultanas or raisins, or maybe something French like croissants. Regardless of what sort of pastries it is, the nearest bakery will go bankrupt 6 months later because none of their customers will be able to go near their shop without being reminded of the great pastry massacre of 2011. You will be content (the medication the nurses make you take will make sure of that), until you convince the nice doctors to release you. Unfortunately you'll be hit by a truck on a busy highway soon after that (but don't blame the truck driver - there's no way he could've seen an old man kissing the white line in the middle of the road in time to avoid impact).


Cheers,

Brendan

Okay...that sounds like a realistic scenario, apart from the "buns containing sultanas and raisins" part; I'm not too keen on fruit in buns!

[leejbaxter]

There are actually 2 methods that I would be quite happy with implementing; either an adaptor (a sort of 'wrapper' or 'emulator' that runs a Windows/Linux driver 'as is'), or a converter (which would actually take the Windows/Linux driver and rewrite it into a form that suits CHAOS). I suppose a hybrid approach may also be a possible implementation.

Thanks to everyone who has offered suggestions so far! I must admit, this forum doesn't seem half as scary as it first seemed on the Wiki!

[Combuster]

This forum doesn't seem half as scary as it first seemed on the Wiki!

We're still dangerous dinosaurs, but only for those who forgot to read the safety manual

[Solar]

This forum doesn't seem half as scary as it first seemed on the Wiki!

We're still dangerous dinosaurs, but only for those who forgot to read the safety manual

LOL...

How to handle an OSDever safely.

A manual written by H.R.H. Combuster and others from the Royal Household.

Chapter 1: How to approach a dinosaur.

Watch "Harry Potter and the Prisoner of Azkaban". Take special note of the hippogryph scene. Extrapolate.

Chapter 2: How to behave if you have a question

Always carry a bunch of dead rats to feed the hippogryph... erm, dinosaur.

Chapter 3: ...