[lkml]   [2008]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: linux-next: Tree for August 14 (sysfs/acpi errors)
    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:
    > >;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

    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2008-08-16 05:21    [W:0.035 / U:20.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site