RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> Вот мой вопрос в рассылке l4ka@ira.uka.de: http://news.gmane.org/gmane.comp.micro-kernel.l4.l4ka.general
> 
> [====================================================]
> 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
> [====================================================]
> И вот ответ (он почему-то не попал в список рассылки, ответ был адресован мне лично):
> [====================================================]
> Valery V. Sedletski wrote:
> > 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?)
> 
> Drivers are reusable in source code form. Recompilation is usually 
> necessary, because most drivers contain virtualization-sensitive 
> instructions (see below).
> 
> > 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?
> 
> 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).
> 
> > 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.
> 
> > 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.
> 
> > 5)  What are "virtualisation-sensitive" instructions, modified by afterburner? Are they just privileged instructions 
> > or something else?
> 
> I suggest reading "Formal requirements for virtualizable third 
> generation architectures" by Popek/Goldberg. Virtualization-sensitive 
> instructions are those instructions that access external machine state, 
> i.e. they access the amount of available resources.
> 
> Kim
> [====================================================]
> 
> WBR,
> Валерий
>

_, _, _, _, _ _, _,_ (_ \| / \ \|\ \| / \ \|_/ , ) \| , \ / \| \\| \ / \| \ ~ ~~~ ~ ~ ~ ~ ~ ~