Ubuntu autofs and module-init-tools contacts

[Ian Kent]

Scott James Remnant wrote:
> 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.

Yes, that was my initial thought.

> 
> 
> 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.

I'm not familiar with MODALIAS, I'll check that.

> 
> 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*).

It appeared to me that it wasn't exactly equivalent.
It seemed that a MODULE_ALIAS() in the module would deal with the
different module name but would fail to map the changed directory name
containing the module whereas an alias in the module-init-tools config
would.

> 
> 
> 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).
> 

As you say, the bigger problem is in fact dealing with different kernels
with the same module-init-tools configuration. This maybe a bit of a gotcha!

> 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*.

The problem I'm seeking to put right started a long long time ago.
We now have two modules in with different names in different directories
that register the same fs name which has to be fixed some time, ;)

Ian