Page 2 of 2

Re: Driver service

Posted: Wed Jul 20, 2011 9:32 pm
by hidnplayr
"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?"

It's a good question, I didnt think of it because all those drivers are inside kernel now.

"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?"

A driver can be disabled by removing/renaming it. Perhaps we can even make a "safe mode" loading only most essential drivers?
Testing drivers always involves developers who can provide the files needed.

Re: Driver service

Posted: Wed Jul 20, 2011 9:36 pm
by CleverMouse
Well, maybe I'm too developer-centric and users indeed don't need to edit the database. In this case a binary file is indeed better.

Re: Driver service

Posted: Wed Jul 20, 2011 9:42 pm
by hidnplayr
I am just presenting my ideas, I'll think about it some more..

Re: Driver service

Posted: Thu Jul 21, 2011 12:16 pm
by art_zh
CleverMouse wrote:art_zh, we develop different systems.
Sadly, you're right.
That's because we think very different concepts.
CleverMouse wrote: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.
It is one of minor reasons; let me mention the other ones:
- I know my code will barely work on every machine smoothly;
- I expect my user is experienced, responsible and clever enough to configure his computer properly;
- the user can be helped by an external device_enumerator (by Linux or MS) if our own one fails;
- the user needs to have a chance to edit/modify his configuration settings when necessary;
- I don't want to spend the rest of my life answering stupid questions like "why is it not working(detected) on my machine?" and fixing all the countless bugs related.
But again, those were minor reasons.

The main reason is: what we can get following PnP-mainstream is yet another flavour of Linux.
CleverMouse wrote:However, even Kolibri-A needs PnP capability e.g. for USB.
What I actually need is hotplug not start-up PnP.
One can manage hotplug hw_detection in a runtime process, and do it better and safer.
In some special cases (i.e. flash disks plugging) the system can be silently restarted after hotplug reconfiguring.
That takes shorter than start-up enumeration, and will follow the spirit of KolibriOS.