All of lore.kernel.org
 help / color / mirror / Atom feed
From: hpa@zytor.com (H. Peter Anvin)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/4] wire up CPU features to udev based module loading
Date: Thu, 07 Nov 2013 14:49:53 -0800	[thread overview]
Message-ID: <527C1911.9030900@zytor.com> (raw)
In-Reply-To: <CAKv+Gu9W-Pu4DGgB-85A3D4Ps9_FLSQgyK3EM7=k7KE1=xsnwg@mail.gmail.com>

On 11/07/2013 02:15 PM, Ard Biesheuvel wrote:
> 
> That would involve repurposing/generalizing a bit more of the existing
> x86-only code than I did the first time around, but if you (as x86
> maintainers) are happy with that, I'm all for it.
> 
> I do have a couple of questions then
> - the module aliases host tool has no arch specific dependencies at
> all except having x86cpu as one of the entries: would you mind
> dropping the x86 prefix there? Or rather add dependencies on $ARCH?
> (If we drop it there, we basically end up with 'cpu:' everywhere)

I think it makes sense to indicate what kind of CPU the string refers
to, as the top-level indicator of what is going on.  This might be
possible to macroize the generation of this prefix, though.

> - in the vendor/family/model case, it may be preferable to drop these
> fields entirely from certain modules' aliases if they match on 'any'
> (provided that the module tools permit this) rather than add
> architecture, variant, revision, etc  fields for all architectures if
> they can only ever match on one

I think that can be CPU dependent.

> - some of the X86_ macros would probable be redefined in terms of the
> generic macros rather than the other way around, which would result in
> some changes under arch/x86 as well, is that acceptable for you?

If you are talking about X86_FEATURE_* then almost certainly no,
although I'm willing to listen to what you have in mind.

	-hpa

WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Andi Kleen <ak@linux.intel.com>
Cc: x86@kernel.org,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	gregkh@linuxfoundation.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	tglx@linutronix.de, Ingo Molnar <mingo@kernel.org>,
	Steve Capper <steve.capper@linaro.org>
Subject: Re: [RFC PATCH 0/4] wire up CPU features to udev based module loading
Date: Thu, 07 Nov 2013 14:49:53 -0800	[thread overview]
Message-ID: <527C1911.9030900@zytor.com> (raw)
In-Reply-To: <CAKv+Gu9W-Pu4DGgB-85A3D4Ps9_FLSQgyK3EM7=k7KE1=xsnwg@mail.gmail.com>

On 11/07/2013 02:15 PM, Ard Biesheuvel wrote:
> 
> That would involve repurposing/generalizing a bit more of the existing
> x86-only code than I did the first time around, but if you (as x86
> maintainers) are happy with that, I'm all for it.
> 
> I do have a couple of questions then
> - the module aliases host tool has no arch specific dependencies at
> all except having x86cpu as one of the entries: would you mind
> dropping the x86 prefix there? Or rather add dependencies on $ARCH?
> (If we drop it there, we basically end up with 'cpu:' everywhere)

I think it makes sense to indicate what kind of CPU the string refers
to, as the top-level indicator of what is going on.  This might be
possible to macroize the generation of this prefix, though.

> - in the vendor/family/model case, it may be preferable to drop these
> fields entirely from certain modules' aliases if they match on 'any'
> (provided that the module tools permit this) rather than add
> architecture, variant, revision, etc  fields for all architectures if
> they can only ever match on one

I think that can be CPU dependent.

> - some of the X86_ macros would probable be redefined in terms of the
> generic macros rather than the other way around, which would result in
> some changes under arch/x86 as well, is that acceptable for you?

If you are talking about X86_FEATURE_* then almost certainly no,
although I'm willing to listen to what you have in mind.

	-hpa



  parent reply	other threads:[~2013-11-07 22:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-07 17:17 [RFC PATCH 0/4] wire up CPU features to udev based module loading Ard Biesheuvel
2013-11-07 17:17 ` Ard Biesheuvel
2013-11-07 17:17 ` [RFC PATCH 1/4] x86: move arch_cpu_uevent() to generic code Ard Biesheuvel
2013-11-07 17:17   ` Ard Biesheuvel
2013-11-07 17:17 ` [RFC PATCH 2/4] cpu: advertise CPU features over udev in a generic way Ard Biesheuvel
2013-11-07 17:17   ` Ard Biesheuvel
2013-11-07 19:33   ` Dave Martin
2013-11-07 19:33     ` Dave Martin
2013-11-07 20:00     ` Ard Biesheuvel
2013-11-07 20:00       ` Ard Biesheuvel
2013-11-07 20:55     ` Ard Biesheuvel
2013-11-07 20:55       ` Ard Biesheuvel
2013-11-07 17:17 ` [RFC PATCH 3/4] scripts/mod: add generic CPU features as module alias Ard Biesheuvel
2013-11-07 17:17   ` Ard Biesheuvel
2013-11-07 17:17 ` [RFC PATCH 4/4] arm64: advertise CPU features using module aliases Ard Biesheuvel
2013-11-07 17:17   ` Ard Biesheuvel
2013-11-07 21:09 ` [RFC PATCH 0/4] wire up CPU features to udev based module loading H. Peter Anvin
2013-11-07 21:09   ` H. Peter Anvin
2013-11-07 21:39   ` Andi Kleen
2013-11-07 21:39     ` Andi Kleen
2013-11-07 22:15     ` Ard Biesheuvel
2013-11-07 22:15       ` Ard Biesheuvel
2013-11-07 22:30       ` Andi Kleen
2013-11-07 22:30         ` Andi Kleen
2013-11-08 15:09         ` H. Peter Anvin
2013-11-08 15:09           ` H. Peter Anvin
2013-11-07 22:49       ` H. Peter Anvin [this message]
2013-11-07 22:49         ` H. Peter Anvin
2013-11-08 10:20         ` Ard
2013-11-08 10:20           ` Ard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527C1911.9030900@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.