Re: [PATCH] Module alias and device table support.

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

> > Consider another example: convenience aliases such as char-major-xxx.
> > Now, I'm not convinced they're a great idea anyway, but if people are
> > going to do this, I'd rather they did it in the kernel, rather than
> > some random userspace program.
> 
> The module munging programs and their configuration are (logically) a part
> of the kernel (configuration). So this goes against the current wave of
> exporting as much as possible from the kernel. And IMHO it places policy
> into the kernel, where it has no place. Plus it enlarges modules, which is
> a consideration for installation/rescue media.

Maybe it helps to put this into a larger perspective, because you both 
have valid points.
Currently the kernel has two mechanisms to request a module (modprobe and 
hotplug) and these also have different ways to map the request to a module 
name. modprobe needs a hardcoded list of module names, so it e.g. knows 
that it should map net-pf-1 to unix. OTOH we generate such a mapping for 
hotplug, but here the mapping is very device specific and requires 
knowledge about kernel structures.
If module loading were the only problem, the alias mechanism would be a 
good solution. We could remove hotplug and let modprobe do the job. 
Unfortunately it's not that easy, as we might want to extend hotplug to a 
more generic event mechanism, which e.g. could be used to replace devfs. 
This means we not only have "load the driver for this new device on this 
bus" events, but also "generate the device nodes for this new driver" 
events. In this context the module alias encoding would be very limited.
So what actually has to be discussed/decided, whether it's ok to special 
case module loading or if we want a generic kernel event mechanism, which 
can map any kind of event to some action. Until this isn't decided, it 
makes little sense to discuss details.

bye, Roman