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