At boot time, kernel should load only the drivers that have been previously detected

[kaoutsis]

At boot time, kernel should load only the drivers that has been previously detected; currently loads all the available drivers found in /boot/beos/system/add-ons/kernel/drivers/bin, plus all the drivers found in /boot/home/config/add-ons/kernel/drivers/bin/

[axeld]

No, it does not. Why would you believe otherwise?

[kaoutsis]

Replying to axeld:

No, it does not. Why would you believe otherwise?

Sorry, i meant to say, that it tries to load the drivers, and if the drivers have no real functionality then they unloaded. Is there any logical point, to load a driver, test it, and if is not need it, then unload it, since from the previously detection process has all the available informations to load only the need drivers?

[stippi]

Maybe if there is both a hash for the hardware and all installed drivers. If both hashes still match, no additional drivers are tried. Anyways, isn't this process quite fast?

[axeld]

I'm still not sure if I understand you. The kernel always only loads the drivers that were requested from an application, never all drivers under .../bin.

When the system boots up, it will first check the drivers (for a specific directory, ie. "disk") before there is a boot device (ie. only the boot loader provided drivers are there), and later, it will eventually scan those drivers again, when it has disk access.

Since the drivers the boot loader provided might not be the ones on disk, there is no way around that behaviour, at least. But is that what you meant? :-)

[kaoutsis]

Let me try with a concrete example: Taken from the syslog (qemu generated/haiku.image -serial stdio)

[...]
ipro100: init_hardware(0x80412f04)
ipro100: no hardware found.
ipro1000: init_hardware(0x804317c4)
ipro1000: no hardware found.
marvell_yukon: init_hardware(0x80418c3c)
marvell_yukon: no hardware found.
nforce: init_hardware(0x80415cd8)
nforce: no hardware found.
rtl8139: init_hardware(0x80411ee0)
rtl8139: no hardware found.
syskonnect: init_hardware(0x80418258)
syskonnect: no hardware found.
via_rhine: init_hardware(0x80412238)
via_rhine: no hardware found.
[...]

the rtl8139 driver is loaded, tested and unloaded,

But from the previously detection process:

[...]
PCI: [dom 0, bus  0] bus   0, device  3, function  0: vendor 10ec, device 8029, revision 00
PCI:   class_base 02, class_function 00, class_api 00
PCI:   vendor 10ec: Realtek Semiconductor Co., Ltd.
PCI:   device 8029: RTL-8029(AS)
PCI:   info: Network controller (Ethernet controller)
PCI:   line_size 00, latency 00, header_type 00, BIST 00
PCI:   ROM base host 00000000, pci 00000000, size 00000000
PCI:   cardbus_CIS 00000000, subsystem_id 0000, subsystem_vendor_id 0000
PCI:   interrupt_line 0b, interrupt_pin 01, min_grant 00, max_latency 00
PCI:   base reg 0: host 0000c100, pci 0000c100, size 00000100, flags 01
PCI:   base reg 1: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   Capabilities: (not supported)
[...]

At that point, there was already available the information that the network driver to be loaded has to be the RTL-8029, and kernel should load that driver, if available, else there is no point probing all the available net drivers

[axeld]

Now I see what you mean. The first "detection" process doesn't detect anything, it's the PCI bus manager that dumps all devices it knows. Furthermore, the kernel has no knowledge of what driver is supposed to handle which device.

The new driver architecture is supposed to help with that issue - it will still be necessary to scan for older drivers, though, and those that aren't just PCI drivers.

[kaoutsis]

Replying to axeld:

Now I see what you mean. The first "detection" process doesn't detect anything, it's the PCI bus manager that dumps all devices it knows. Furthermore, the kernel has no knowledge of what driver is supposed to handle which device.

Exactly! a) the first "detection" process doesn't detect anything. Why not? b) the kernel has no knowledge of what driver is supposed to handle which device. Why not? Now let's forget for a moment the technical part (and the above example). Would it be nicer from a _logical_ point of view, the kernel to have a reliable discover mechanism, with the ability to query the actual hardware parts, and then load only the needed drivers?

The new driver architecture is supposed to help with that issue - it will still be necessary to scan for older drivers, though, and those that aren't just PCI drivers.

Ok. At least, i find i little annoying the fact that the kernel probing non-existing drivers, putting aside the time penalty to load and unload the driver(s). Of course, the central idea was (is) to make the kernel technically smarter, thus the ticket was for the 'enhancement' idea, there is no actual bug anywhere:-)

[kaoutsis]

Replying to stippi:

Maybe if there is both a hash for the hardware and all installed drivers. If both hashes still match, no additional drivers are tried.

You mean that after the kernel have found the boot device, could access a database of all available driver ids, probing the hardware, found the corresponding driver ids, create a small database with the drivers that correspond to the real hardware parts and then will load only those needed drivers (which correspond to the hardware), when there is a request from a userspace application? That was the idea :-)

Anyways, isn't this process quite fast?

yes, my concerns are:

1) If the process could be more faster. If a machine have a network card, that has a known id, that id is stored (or can be stored to a database, and there is 10 available drivers (in near future may be 20), is there a reason for the kernel to probe all the available drivers, to find the right one?

2) a kind of 'haiku kernel prestige': haiku kernel loads only the driver that corresponds to a physical (or logical) device