Re: Unmodified driver reuse and Afterburner

On Wed, 20 Jun 2007 20:21:13 +0200, Kim-Thomas Moeller wrote:

>Most Linux driver source code is processor independent. Unfortunately, 
>some architecure-specific kernel functions that contain sensitive 
>instructions are inlined into driver code (e.g. in, out).
>

But, as I understand, usermode task can issue IN or OUT instructions. -- It can obtain I/O rights from
some hardware manager (like l4io in l4env), they are just mapped as i/o flexpages. And if flexpages are mapped into
task i/o address space, the task can do i/o on these ports directly. Am I not 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?
>
>Both techniques, driver reuse and L4Ka virtualization, are applicable to 
>any ordinary OS. However, only Linux implementations are publicly 
>available. I guess cross-OS driver reuse is possible.
>

But, the problem of source code availability for all device drivers remains, doesn't it? So, it is "theoretically"
posiible to apply this approach to windows drivers, but in practice, the inavailability of their source code prevents
this approach from working?

>> 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)
>
>As far as I know, the afterburner currently assumes 32-bit protected 
>mode for the kernel. Support of 16-bit user code depends on the 
>hypervisor used.
>

So, in case of L4 as a hypervisor, it is not possible to execute 16-bit code? Or, some possibility exists? For example, Adam 
Lackorzynsky on [email protected] mailing list, says, that in case of Fiasco, there is a possibility to reserve
some GDT slots for usermode tasks. (this may be useful for creating 16-bit segments descriptors) -- Maybe some way exists, to 
adapt Afterburner approach to mixed 16-bit/32-bit code?

And does anybody know about mapper application, is the special support for each "reused" device driver needed in this 
mapper?
>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?)