On Sat, 2008-08-16 at 04:57 +0200, Andi Kleen wrote: > >> Extract is: > >> > >> XXX adding modparam:'acpi.power_nocheck' 34 (ffffffff806a4cf0) > > ... > >> XXX adding modparam:'acpi.acpica_version' 45 (ffffffff806a4ea8) > > > > Two different "modules" use the same prefix, which does not work with > > the current logic, they need to live next to each other in the sequence > > of options. > > Sequence of options being defined by link order? Yeah, they are stored in a global array __start___param, and the current code expects the prefixes to be sorted, so the sysfs directories can be created for every first new prefix. > > This adds a new option: > > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=1382827e93799ec07790849e361267993cfe549e > > which specifies MODULE_PARAM_PREFIX="acpi." in: > > drivers/acpi/power.c > > In the same way as: > > drivers/acpi/system.c > > > > Seems, two different modules should not declare parameters in different > > locations, and use the same MODULE_PARAM_PREFIX. > > That seems bogus to me. Assuming we have some code in a module and then split > it out into two different modules. Or move an option from one file to another. > Would we need to change the option name then? They have been module options, not prefixed kernel parameters so far, and the prefix was just the module name. So it just strikes back, that acpi uses generic names for the modules, there would have been no problem if "power" would be called "acpi_power" and the options would just be "acpi.acpica_version" and "acpi_power.nocheck". But well, there are driver modules just called "option", so acpi is not that bad. :) > I think the generic params code should be fixed to handle this. We could try to look up existing directories to use instead of expecting that we need to create and own them. I guess, we have the same issue if we compile the code as a module and load it later, while some other built-in code or module has already used the same prefix. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
