Unmodified driver reuse and Afterburner

"Valery V. Sedletski" <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.l4ka.general
Message-ID <[email protected]>
I'm contributing to an OS/2 cloning project (www.osFree.org) and there is some hope to reuse unmodified 
Linux device drivers. Here, the L4Ka Unmodified driver reuse and Afterburner projects seem to be very 
promising. But I still have some questions that are not clear. So, can someone answer the questions regarding 
these technologies?

1)  The web page about Unmodified driver reuse project states that Linux drivers are unmodified. Does that 
mean that they are unmodified in their _source_code_ form, but recompilation is required? Or, they remain 
unmodified in their binary form? (Is there a possibility to be binary compatible with native Linux?)

2)   As I understand, Linux drivers are platform-neutral. So, they are probably do not work with hardware 
directly, but instead, call routines in architecture-specific part of kernel, which operate hardware directly. 
So, only architecture-specific part of kernel must be modified to paravirtualize Linux kernel. And drivers remain 
untouched. (Maybe, even no recompilation required). Am I right?

3)  Is the unmodified driver reuse project and L4Ka virtualisation technologies all Linux or UNIX specific? 
Does they rely on some Linux features (drivers platform neutrality etc.). Or, is it possible to reuse unmodified 
Windows drivers? If there is a possibility to paravirtualise ReactOS kernel by using Afterburner project, then, is 
a source code for Windows device drivers required?

4)  Must be the Operating System sources, for which Afterburner is applied to, to be 32-bit clean, or they 
(sources) can contain 16-bit code? (Maybe, it is possible to use Afterburner with OS/2 sources? These 
sources contain 16-bit parts along with 32-bit ones)

5)  What are "virtualisation-sensitive" instructions, modified by afterburner? Are they just privileged instructions 
or something else?

6)  The Device Driver Reuse project is based on the mapper application inside Device driver OS (DD/OS). 
The Client OS calls this mapper and it translates this request into the form, specific to DD/OS kernel. The 
question is: is the individual support for each reused device driver required in this mapper, or the mapper is 
"driver-independent"? How can this be made (driver independence)? The ioctl requests to different drivers are 
different, so, it seems that the specific support is required in mapper for each driver. (In other words, there is 
support in mapper for HDD driver and LAN card driver, for example. But if we want to add a new driver to 
DD/OS, must the mapper be modified or not? So, must the mapper support each driver specifically (is this 
support hardcoded in mapper), or is it general for different drivers?)

Thanks in advance,
WBR,
Valery
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.