On Wed, 2009-04-15 at 00:31 +0800, Ian Kent wrote: > My initial testing showed that this didn't work in all cases I checked. > The only reason we need anything at all is backward compatibility. > The whole idea here is to get rid of the need to manually load the > autofs module at all. > It's especially important that any auto-loading aliases are *only* done inside the module. We've had several bugs where auto-loading aliases were hacked using module-init-tools options files, and they had got out of date with the kernel, so stopped working.
(Most notably, the floppy module)
A recent audit of all of the module-init-tools options we carried ended
up revealing that the number that were still applicable could actually
be counted with single digits out of literally a hundred different
lines.
So I'd definitely suggest not considering it an option worth taking.
I know the driver core system very well, so I'd be more than happy to
help you figure out the best way to do things. In general, it's easy
though.
Each subsystem exports a "MODALIAS" string that matches devices found on
that subsystem, your module can gain wildcard aliases to match through
the use of the MODULE_DEVICE_TABLE macro.
In addition, there are other magic classes of aliases such as the
{char,block}-major-nnn-yyy style aliases which cause auto-loading on
device node open - these also have kernel macros (one per block) to
support them.
And if all else fails, you can always just use MODULE_ALIAS() to add
your own custom alias - which is exactly equivalent to an alias line for
modprobe (indeed they get *turned into them*).
You mention compatibility, one additional compelling reason for not
doing things in config files is actually compatibility. You say that
module names are changing, etc.
If you do things in configuration files, you have a lot of complexity to
support a system which might be running an older kernel version or the
newer one (or indeed, a system which switches between the two).
If you do things in-module, then whichever kernel the user boots *will
still work* because the in-module configuration is used *for that kernel
only*.
Scott
--
Scott James Remnant
sc...@canonical.com
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
