linux-kernel - Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ac3eb2510902231347u4ff8e3a4ia69ef3e5c189c756@mail.gmail.com>
Date:	Mon, 23 Feb 2009 22:47:20 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Thomas Renninger <trenn@...e.de>
Cc:	alan-jenkins@...fmail.co.uk, Kay Sievers <kasievers@...e.de>,
	Ingo Molnar <mingo@...e.hu>,
	Matthew Garrett <mjg59@...f.ucam.org>, davej@...emonkey.org.uk,
	linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org
Subject: Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules

On Mon, Feb 23, 2009 at 22:12, Thomas Renninger <trenn@...e.de> wrote:
> On Thursday 19 February 2009 12:54:06 pm Alan Jenkins wrote:
>> On 2/18/09, Ingo Molnar <mingo@...e.hu> wrote:
>> > * Matthew Garrett <mjg59@...f.ucam.org> wrote:
>> >> On Wed, Feb 18, 2009 at 07:31:37PM +0100, Ingo Molnar wrote:
>> >> > Nice fix! Where does this information come from? Distro module
>> >> > ordering magic? It's rather non-trivial.
>> >>
>> >> Pretty much. p4-clockmod is never the preferred option because
>> >> it does no voltage scaling. speedstep-centrino is now almost
>> >> entirely functionally replaced with acpi-cpufreq. The
>> >> powernow-k8 issue was a personal communication from davej.
>> >
>> > I'm wondering whether that priority order should/could be
>> > expressed in the module space too - so that distros wouldnt have
>> > to replicate this. This is really a piece of information the
>> > kernel is best at maintaining.
>>
>> The latest development version of module-init-tools (in the git tree)
>> is designed to preserve the kernel link order when resolving builtin
>> aliases.  If you have two modules which provide the alias "pci:123",
>> they will be loaded in the same order as if they were builtin drivers.
>>
>> It should work if all the cpufreq drivers provide an alias
>> "cpufreq-driver" and userspace just does "modprobe cpufreq-driver".
>> You just need to be sure none of the cpufreq drivers provide *other*
>> aliases which cause them to be loaded earlier, by udev or some other
>> bootscript.
> I wonder whether a "cpu:vendor:fam:model:flags:..." alias makes sense.
> This would solve autoloading of most cpufreq drivers, but it never looked
> important enough.
> Other drivers that could make use of this:
>  - k8temp/k10temp (Don't know about this one, but AFAIK there exists an
>    MSR to read out temperature on latest AMD for which a hwmon driver
>    is/should be written)?
>  - Microcode update?
>  - more?

I thought about something similar, because distros probably do not
want to load all modules shipped with a single alias, but only the
ones match matching the actual hardware.

Unfortunately, the stuff in /sys/devices/system/cpu/ can not be used
to export a modalias until it is converted to proper buses and "struct
device"s.

If we come up with an extensible modalias string, the system boot
scripts can compose, and call modprobe to load cpufreq modules, it
sounds like a good thing to do.

Some day, the properly converted /sys/devices/system/ devices will
work, and can trigger the auto-loading out-of-the-box. If possible,
the modaliases added to the modules could be directly used for the
future system devices.

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