Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Jun 18, 2019 8:15 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 19 posts ]  Go to page 1 2 Next
Author Message
 Post subject: Driver service
PostPosted: Mon Jul 18, 2011 1:54 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
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.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 2:16 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
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.


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 9:18 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
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.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 12:16 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
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.


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 12:32 pm 
Offline
Public Relations
User avatar

Joined: Mon Jun 07, 2010 12:01 pm
Posts: 1879
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 :wink:


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 12:56 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
yogev_ezra wrote:
hidnplayr: Maybe you can describe your idea in more detail so that stupid people like me will also understand it :wink:


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

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 1:11 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
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. :shock:


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 1:59 pm 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 794
may be just provide not system-service, but kernel-side thread? And also make possibility of changing/disabling it on compile-time?


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 2:11 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
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? ;)

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 7:41 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
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.


Top
   
 Post subject: Re: Driver service
PostPosted: Mon Jul 18, 2011 11:29 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
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.


Top
   
 Post subject: Re: Driver service
PostPosted: Tue Jul 19, 2011 12:51 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
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.


Top
   
 Post subject: Re: Driver service
PostPosted: Tue Jul 19, 2011 2:01 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
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.


Top
   
 Post subject: Re: Driver service
PostPosted: Wed Jul 20, 2011 6:18 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
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.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
 Post subject: Re: Driver service
PostPosted: Wed Jul 20, 2011 9:22 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
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.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 19 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited