This series implements automatic module loading based on optional CPU features,
and tries to do so in a generic way.
Typical usage would look like this:
static struct cpu_feature mod_cpu_feature[] = {
{ HWCAP_CRC32 },
{}
};
MODULE_DEVICE_TABLE(cpu, mod_cpu_feature);
where (on the
I assumed he was referring to just dropping those fields of they didn't make
sense for the architecture. That would make sense to do.
Andi Kleen wrote:
>> - the module aliases host tool has no arch specific dependencies at
>> all except having x86cpu as one of the entries: would you mind
>> dro
On 11/07/2013 11:49 PM, H. Peter Anvin wrote:
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 co
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
> - 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)
Should be fine.
> - in t
On 7 November 2013 22:39, Andi Kleen wrote:
> On Thu, Nov 07, 2013 at 01:09:41PM -0800, H. Peter Anvin wrote:
>> On 11/07/2013 09:17 AM, Ard Biesheuvel wrote:
>> > This series implements automatic module loading based on optional CPU
>> > features,
>> > and tries to do so in a generic way. Curren
On Thu, Nov 07, 2013 at 01:09:41PM -0800, H. Peter Anvin wrote:
> On 11/07/2013 09:17 AM, Ard Biesheuvel wrote:
> > This series implements automatic module loading based on optional CPU
> > features,
> > and tries to do so in a generic way. Currently, 32 feature bits are
> > supported,
> > and ho
On 11/07/2013 09:17 AM, Ard Biesheuvel wrote:
> This series implements automatic module loading based on optional CPU
> features,
> and tries to do so in a generic way. Currently, 32 feature bits are supported,
> and how they map to actual CPU features is entirely up to the architecture.
NAK.
We
This series implements automatic module loading based on optional CPU features,
and tries to do so in a generic way. Currently, 32 feature bits are supported,
and how they map to actual CPU features is entirely up to the architecture.
There is some GCC attribute foo in here which people may object
9 matches
Mail list logo
