Board.KolibriOS.org

Hello guys and girls,

I think it's time to develop a system service for KolibriOS, wich is responsible for detecting the harware present in a computer and load the needed drivers.
(sound, network, video, USB, ..)

Pretty much like the program I wrote for net branch (http://redmine.kolibrios.org/projects/k ... ons/netcfg) but more universal.

Is it a good idea? any suggestions?
If so, I'll take some time to develop it before continuing on net-branch.

svn/kernel/branches/kolibri-acpi ?

Serge wrote:Заключительный этап. Переход к полноценной драйверной модели.
- к существующим спискам устройств acpi и pci добавляются списки логических устройств и драйверов/сервисов. Каждое устройство монтируется на виртуальную шину. Каждый драйвер реализует необходимые обработчики подключения и отключения устройства, управления питанием и т.д. Существующая сейчас возможность резервировать любые порты ввода-вывода и линии irq а также читать и писать конфигурационное пространство любых PCI устройств закрывается. По крайней мере для драйверов пользовательского режима. Все подобные операции осуществляются только с учётом ресурсов, используемых устройством.

The final stage: to implement a full-featured driver model.
- to add lists of logical devices and drivers/services to accompany the existing lists of ACPI and PCI devices.
- every device shall be mountable to the virtual bus.
- every driver must implement necessary attachement/detachement/PM handlers etc.
- to exclude any possibility of reserving random I/O ports, IRQs; and to deny any configspace access (at least by usermode drivers)
- to delegate such operations to responsible code which can analyse device's resourses properly.

Speaking for myself, I don't like the idea. It will look too much like an asm-aided linux.

Oh, I didnt realise it's already being worked on :s

What dont you like about it, art_zh ?

To me, it just seems the logical next step.

I agree this can be a straight and safe way of building a 'universal' desktop system which recognizes the platform it runs and tunes up all the drivers correspondingly.
But we have no chance to develop 1000s of drivers needed. And even porting open-source Linux drivers will be a problem unless we accept the entire Linux driver model.
Just look svn/drivers/ddk to see what I mean. What we get on this way is a small asm-kernel surrounded with hundreds of alien C-megadrivers.

But there is another way to move: we stay with or current driver model, and leave reasonable freedom of resouce access/sharing for application.
In this case, very accurate code alignment needed to communicate with the given hardware, and the user has to do such an alignment during automatic, semi-automatic or manual OS installation.
We cannot guaranty this will work for any PC platform, and therefore I put forward the idea of "selected platforms" the System supports.
AMD RS780+ and Fusion/Hudson are such platforms: my Kolibri-A manages this hardware with some new tricks unavailable with the trunk kernel.
yogev_ezra bravely builds his own flavour of KolibriOS on eBox platform despite many problems and objectives.
He has a TARGET, and a WILL to go, and he doesn't care about compatibility etc.

art_zh: Thanks for the kind words!
hidnplayr: Maybe you can describe your idea in more detail so that stupid people like me will also understand it

yogev_ezra wrote:hidnplayr: Maybe you can describe your idea in more detail so that stupid people like me will also understand it

I only proposed to make a service (application) wich detects hardware, and loads the appropriate driver.
art_zh seems to be speaking of a new driver model, I wasnt planning for that. (Also I'm not going to port 1000 drivers in C code.)

eg, you will not have to find out what soundcard you have and rename the driver to sound.obj

What I had in mind is an application wich has a pre-compiled list of all hardware supported by all current drivers.
If the required driver is not present, the user might be notified that it is available online.

I'd really appreciate some comments on this from Serge, as he has written the sound system and ported ATIKMS driver etc

hidnplayr wrote:I only proposed to make a service (application) wich detects hardware, and loads the appropriate driver.

But do we really need this software running every time during the startup?
I think about an OS-installer (on a 'live' CD) that detects all the hardware and builds the kernel and drivers correspondingly. And also - helps the user to tune-up desirable bootloading method safely and cleverly.

Such an installer will not necessarily be written on fasm neither run on KolibriOS platform...

hidnplayr wrote:I'd really appreciate some comments on this from Serge, as he has written the sound system and ported ATIKMS driver etc

I like this stuff, and use it very actively. I only said it looks very odd to KOS, and it will be a bad idea to use it as a new standard driver model.
My dream is one day it will be rewritten in fasm.

may be just provide not system-service, but kernel-side thread? And also make possibility of changing/disabling it on compile-time?

art_zh wrote: But do we really need this software running every time during the startup?

Yes, because all needed drivers must be loaded on startup, no?

Offcourse, the application should remember last configuration and not have to re-do all the hard work every time...

art_zh wrote: I think about an OS-installer (on a 'live' CD) that detects all the hardware and builds the kernel and drivers correspondingly. And also - helps the user to tune-up desirable bootloading method safely and cleverly.

And how exactly will those drivers be loaded at startup of kolibri?

hidnplayr
As to me, it's a very good idea. I think about the same already for 6 month.
New driver model is under construction, and it is very different from the current model. So it seems that auto configurator is the best idea for the current model.

I think that the kernel should detect all PnP devices - e.g. scan the PCI bus and get vendor ID/device ID/class for every device - when booting and load the corresponding drivers. The list of existing drivers should be in a text file loaded by the kernel at the boot time; format of file should allow things like "if a PCI device has vendor ID = 0x8086 and class/subclass = 04/03, load the COFF driver sound.obj", and sound.obj tests the concrete device ID - this keeps the file from growing. I need something like that for USB buses, which are scanned by the kernel thread, so I will sometimes program this.

hidnplayr wrote:And how exactly will those drivers be loaded at startup of kolibri?

here is the answer:

CleverMouse wrote:"if a PCI device has vendor ID = 0x8086 and class/subclass = 04/03, load the COFF driver sound.obj"

And I see no need to do this check all the time during the OS start-up.

art_zh, we develop different systems.
You work on Kolibri-A branch and think from a perspective of an embedded system with fixed PCI/PCI-e hardware. Indeed, such a system doesn't need to re-enumerate PCI bus at every startup. However, even Kolibri-A needs PnP capability e.g. for USB.
I work on a generic desktop system which can be installed e.g. on a flash drive and booted on significantly different computers without any changes in the system. For such a system, a dynamic configuration is absolutely necessary.
And you're free not to port any code from trunk to the Kolibri-A branch.

CleverMouse wrote:I think that the kernel should detect all PnP devices - e.g. scan the PCI bus and get vendor ID/device ID/class for every device - when booting and load the corresponding drivers. The list of existing drivers should be in a text file loaded by the kernel at the boot time; format of file should allow things like "if a PCI device has vendor ID = 0x8086 and class/subclass = 04/03, load the COFF driver sound.obj", and sound.obj tests the concrete device ID - this keeps the file from growing. I need something like that for USB buses, which are scanned by the kernel thread, so I will sometimes program this.

Why place it in kernel? It does not need to be.
A program/service is easier to maintain and safer I believe.

Also, why use a text file? A binary file with fixed markup has many advantages.
1. It's smaller
2. It's easier to parse
3. It should not be easy to change for users anyway

Also, for network drivers, it's not easy to use only vendor + class/subclass ID's, For example, there are already 3 drivers for realtek cards, wich are very different devices.
It's not a good idea to put all that code in one driver.
So the file listing devices should be flexible, eg a combination of different ID's, ignoring for example class or device id in some cases should be possible.

The kernel is responsible for loading and calling all hardware drivers. What if autorun.dat references a resource on a storage device supported by dynamically loaded driver?

A binary file is also an option. However, I'm not sure that "it should not be easy to change for users anyway" - what if a new driver needs to be tested? what if the system doesn't boot due to some driver and this driver should be disabled?

Yes, file format should be flexible. I thought about one record being several conditions with implied AND, either of which can test predefined characteristics - vendor ID, device ID, class/subclass code.