Matthew Burgess wrote:
Alexander E. Patrakov wrote:
WARNING: the patch is incomplete. It assumes that SCSI module
autoloading rules are already added, but they are in fact not.
Erm, they are in the udev-config-6.rules file, unless you've spotted a
problem with those?
They don't load the correct driver for OnStream SCSI tapes.
+ <para>Create some rules that work around broken sysfs attribute
creation
+ timing in linux-2.6.15:</para>
Can these be put in our existing rules file? I'd rather just have 1
rules file if at all possible.
No. This should go before any user-specified rules, even if the user
numbers them below 25.
+ <sect3>
+ <title>A kernel module is not loaded automatically</title>
+ <para>Udev loads only modules that have bus-specific aliases,
and only if
+ the bus driver properly exports the wanted aliases to <systemitem
+ class="filesystem">sysfs</systemitem>. In other cases, one should
+ arrange module loading by other means. With linux-2.6.15, Udev
is known
Are these "other means" more or less always via S05modules? If so, I
think it'd be more helpful to folks to be explicit about that. Or are
there cases where S05modules won't work, or will do the wrong thing?
"Other means" = either S05modules or "install" rules in modprobe conf,
depending on whether the module is a wrapper.
+ <para>Otherwise, udev is not supposed to load this
+ module with this kernel version.</para>
I couldn't understand what case the sentence above referred to. Here's
the cases I think we can encounter:
1) modalias file present
1.1) modalias contents match the module alias in the driver
1.1.1) module alias exported to uevent environment
1.1.2) module alias not exported to uevent environment
1.2) modalias contents don't match the module alias in the driver
2) modalias file not present
1.1.1 is an example of a driver that Udev will handle properly
1.1.2 describes the status of the input subsystem in Linux-2.6.15.x
1.2 sounds like a bug to me, do we have any examples of in-kernel
drivers like this?
1.2 actually sounds like "the user is looking at the wrong driver" or
"that driver doesn't have modalias because the developers are lazy". The
second case happens only with out-of-tree proprietary drivers.
2 describes the status of the ISA and IDE subsystems in Linux-2.6.15.x
Are there any other cases we can hit?
No.
Now that I understand how a device driver module is loaded, I have one
last question. What triggers a modular *bus* driver to be loaded? Or
does the kernel automatically try to load support for every bus that has
a driver compiled for it (be that modular or compiled in)?
There are the following cases.
1) Driver for this bus cannot be modular (e.g., PCI). No problem.
2) The bus is virtual (like INPUT), but the driver can be modular (for
INPUT, that's hidden behind CONFIG_EMBEDDED). Nobody loads the module.
3) The bus is physical and begins with a controller. This controller is
usually a PCI device. E.g., let's look at the USB bus. A typical
controller looks like:
0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
1.1 Controller (rev 1a)
0000:00:07.2 0c03: 1106:3038 (rev 1a)
The proper PCI device driver here is uhci-hcd, which depends on usbcore.
Usbcore is a USB bus driver. You already know why and how udev loads the
driver for this PCI device (i.e., uhci-hcd). Since this driver depends
(as seen in modules.dep) on usbcore, module-init-tools automatically
load usbcore before uhci-hcd. Thus, you have the USB bus driver loaded
if there is at least one USB host controller on your PCI bus.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
