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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : valerius
Subj : А вот вопрос, однако...
Вот мой вопрос в рассылке l4ka@ira.uka.de: news.gmane.org

[====================================================]
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,
Валерий


Fri 22 Jun 2007 10:30 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) Gecko/2005



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.