Re: [PATCH 00/31] Add a lot of module alias statements

[Kay Sievers]

On Tue, Mar 10, 2009 at 21:38, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> On Tue, 10 Mar 2009 19:22:16 +0100, Kay Sievers wrote:
>> On Tue, Mar 10, 2009 at 19:13, Scott James Remnant <scott@xxxxxxxxxxxxx> wrote:
>> > On Tue, 2009-03-10 at 18:55 +0100, Jean Delvare wrote:
>> >> On Tue, 10 Mar 2009 17:49:51 +0000, Scott James Remnant wrote:
>> >> > With current modprobe those files are turned into a binary index that
>> >> > can be read and processed *much* faster.
>> >>
>> >> What would prevent the same binary index from being generated from
>> >> user-provided module aliases?
>> >
>> > Why go to all that effort when adding the alias to the kernel is just a
>> > one-line change, and then it shows up along with all of the other
>> > aliases that depmod generates the existing binary index from?
>
> Well, _you_ used the performance improvement as one of the arguments to
> explain why your patches would be good to have. It's only fair to let
> us know if and why there is a relation between where the modalias comes
> from (kernel module or user config) and the possibility to improve
> performance.
>
>> The problem, with a new kernel or module, we know for forever, that we
>> have to run depmod, but this is not the case for depmod config files,
>> and not really to manage, to require a binary index update here.
>
> You are not really clear, sorry. As Scott said before, modprobe is run
> many many times during boot, so it would seem fair to build a binary
> index for all configuration files if it helps with performance. A
> simple time comparison between all configuration files and the index
> should be much faster than parsing all configuration files each time
> modprobe is run, shouldn't it?

It's the long list of fnmatch() calls which is expensive, not the
reading/parsing of the files. It could certainly be implemented, but
it would heavily complicate things. You would need to ignore the
binary index if one config file does not match the current index, or
re-generate it silently, or do other rather complicated stuff to make
things predictable. We would likely better go with a modprobe daemon,
than doing anything like this. But the goal is to have almost no
config files, so we do not need complex optimizations for them. At
least that looks like the best compromise today. :)

>> But the main point is that we want to put information where it
>> belongs: in the module itself. Just look at the crap we ship in
>> /etc/modprobe* and you know that externally maintained configs for
>> kernel modules just don't work. :)
>
> This I certainly agree with (for module aliases which do have an
> interest, that is), no question about that.

Yeah, and there should only be a few things needed. Most of the
content of /etc/modprobe* are missing kernel aliases, module options
which should be made the default in the module, and kernel driver bugs
which should be fixed in the kernel, not in module config files.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/