Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [tip:x86/microcode] x86, microcode: Move to a proper location
3 views
Skip to first unread message
H. Peter Anvin
Jan 14, 2014, 11:20:03 AM1/14/14
to
On 01/14/2014 05:58 AM, tip-bot for Borislav Petkov wrote:
> Commit-ID: bad5fa631fca5466401cd4a48e30cc1f1cb6101e
> Gitweb: http://git.kernel.org/tip/bad5fa631fca5466401cd4a48e30cc1f1cb6101e
> Author: Borislav Petkov <b...@suse.de>
> AuthorDate: Sun, 1 Dec 2013 18:09:58 +0100
> Committer: Borislav Petkov <b...@suse.de>
> CommitDate: Mon, 13 Jan 2014 20:00:12 +0100
>
> x86, microcode: Move to a proper location
>
> We've grown a bunch of microcode loader files all prefixed with
> "microcode_". They should be under cpu/ because this is strictly
> CPU-related functionality so do that and drop the prefix since they're
> in their own directory now which gives that prefix. :)
>
> While at it, drop MICROCODE_INTEL_LIB config item and stash the
> functionality under CONFIG_MICROCODE_INTEL as it was its only user.
>
Quite frankly I would be much happier if we didn't stash so much under
arch/x86/kernel/cpu ... quite frankly it feels like almost *anything*
could go under there. The microcode code, for example, could go under
its own subtree.
Both kernel and kernel/cpu really could use a house cleaning and
actually separate things out into better categories and avoid needlessly
deep pathnames.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> Commit-ID: bad5fa631fca5466401cd4a48e30cc1f1cb6101e
> Gitweb: http://git.kernel.org/tip/bad5fa631fca5466401cd4a48e30cc1f1cb6101e
> Author: Borislav Petkov <b...@suse.de>
> AuthorDate: Sun, 1 Dec 2013 18:09:58 +0100
> Committer: Borislav Petkov <b...@suse.de>
> CommitDate: Mon, 13 Jan 2014 20:00:12 +0100
>
> x86, microcode: Move to a proper location
>
> We've grown a bunch of microcode loader files all prefixed with
> "microcode_". They should be under cpu/ because this is strictly
> CPU-related functionality so do that and drop the prefix since they're
> in their own directory now which gives that prefix. :)
>
> While at it, drop MICROCODE_INTEL_LIB config item and stash the
> functionality under CONFIG_MICROCODE_INTEL as it was its only user.
>
Quite frankly I would be much happier if we didn't stash so much under
arch/x86/kernel/cpu ... quite frankly it feels like almost *anything*
could go under there. The microcode code, for example, could go under
its own subtree.
Both kernel and kernel/cpu really could use a house cleaning and
actually separate things out into better categories and avoid needlessly
deep pathnames.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
Jan 14, 2014, 11:30:01 AM1/14/14
to
* H. Peter Anvin <h...@zytor.com> wrote:
> On 01/14/2014 05:58 AM, tip-bot for Borislav Petkov wrote:
> > Commit-ID: bad5fa631fca5466401cd4a48e30cc1f1cb6101e
> > Gitweb: http://git.kernel.org/tip/bad5fa631fca5466401cd4a48e30cc1f1cb6101e
> > Author: Borislav Petkov <b...@suse.de>
> > AuthorDate: Sun, 1 Dec 2013 18:09:58 +0100
> > Committer: Borislav Petkov <b...@suse.de>
> > CommitDate: Mon, 13 Jan 2014 20:00:12 +0100
> >
> > x86, microcode: Move to a proper location
> >
> > We've grown a bunch of microcode loader files all prefixed with
> > "microcode_". They should be under cpu/ because this is strictly
> > CPU-related functionality so do that and drop the prefix since they're
> > in their own directory now which gives that prefix. :)
> >
> > While at it, drop MICROCODE_INTEL_LIB config item and stash the
> > functionality under CONFIG_MICROCODE_INTEL as it was its only user.
> >
>
> Quite frankly I would be much happier if we didn't stash so much
> under arch/x86/kernel/cpu ... quite frankly it feels like almost
> *anything* could go under there. The microcode code, for example,
> could go under its own subtree.
>
> Both kernel and kernel/cpu really could use a house cleaning and
> actually separate things out into better categories and avoid
> needlessly deep pathnames.
be a first good step. It's all kernel code, there's other
subdirectories there that are kernel code ('pci/', 'platform/', etc.),
so there's little point in continuing the historic accident of a
'kernel/' subdirectory.
Once that is done we can move certain things outside as well - for
example arch/x86/cpu/perf/ could probably move to arch/x86/events/,
because that code is not about CPU events anymore either.
Thanks,
Ingo
Borislav Petkov
Jan 14, 2014, 11:40:02 AM1/14/14
to
On Tue, Jan 14, 2014 at 05:22:03PM +0100, Ingo Molnar wrote:
> Absolutely. I think moving arch/x86/kernel/cpu/ to arch/x86/cpu/
> would be a first good step. It's all kernel code, there's other
> subdirectories there that are kernel code ('pci/', 'platform/', etc.),
> so there's little point in continuing the historic accident of a
> 'kernel/' subdirectory.
>
> Once that is done we can move certain things outside as well - for
> example arch/x86/cpu/perf/ could probably move to arch/x86/events/,
> because that code is not about CPU events anymore either.
All fine and dandy with me, but I'd prefer to do this after the merge
> Absolutely. I think moving arch/x86/kernel/cpu/ to arch/x86/cpu/
> would be a first good step. It's all kernel code, there's other
> subdirectories there that are kernel code ('pci/', 'platform/', etc.),
> so there's little point in continuing the historic accident of a
> 'kernel/' subdirectory.
>
> Once that is done we can move certain things outside as well - for
> example arch/x86/cpu/perf/ could probably move to arch/x86/events/,
> because that code is not about CPU events anymore either.
window, i.e. for 3.15. Rushing it now would just cause unnecessary
trouble IMO.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
H. Peter Anvin
Jan 14, 2014, 11:50:04 AM1/14/14
to
On 01/14/2014 08:36 AM, Borislav Petkov wrote:
> On Tue, Jan 14, 2014 at 05:22:03PM +0100, Ingo Molnar wrote:
>> Absolutely. I think moving arch/x86/kernel/cpu/ to arch/x86/cpu/
>> would be a first good step. It's all kernel code, there's other
>> subdirectories there that are kernel code ('pci/', 'platform/', etc.),
>> so there's little point in continuing the historic accident of a
>> 'kernel/' subdirectory.
>>
>> Once that is done we can move certain things outside as well - for
>> example arch/x86/cpu/perf/ could probably move to arch/x86/events/,
>> because that code is not about CPU events anymore either.
>
> All fine and dandy with me, but I'd prefer to do this after the merge
> window, i.e. for 3.15. Rushing it now would just cause unnecessary
> trouble IMO.
>
Oh, absolutely.
> On Tue, Jan 14, 2014 at 05:22:03PM +0100, Ingo Molnar wrote:
>> Absolutely. I think moving arch/x86/kernel/cpu/ to arch/x86/cpu/
>> would be a first good step. It's all kernel code, there's other
>> subdirectories there that are kernel code ('pci/', 'platform/', etc.),
>> so there's little point in continuing the historic accident of a
>> 'kernel/' subdirectory.
>>
>> Once that is done we can move certain things outside as well - for
>> example arch/x86/cpu/perf/ could probably move to arch/x86/events/,
>> because that code is not about CPU events anymore either.
>
> All fine and dandy with me, but I'd prefer to do this after the merge
> window, i.e. for 3.15. Rushing it now would just cause unnecessary
> trouble IMO.
>
-hpa
Ingo Molnar
Jan 14, 2014, 12:40:03 PM1/14/14
to
> On 01/14/2014 08:36 AM, Borislav Petkov wrote:
> > On Tue, Jan 14, 2014 at 05:22:03PM +0100, Ingo Molnar wrote:
> >> Absolutely. I think moving arch/x86/kernel/cpu/ to arch/x86/cpu/
> >> would be a first good step. It's all kernel code, there's other
> >> subdirectories there that are kernel code ('pci/', 'platform/', etc.),
> >> so there's little point in continuing the historic accident of a
> >> 'kernel/' subdirectory.
> >>
> >> Once that is done we can move certain things outside as well - for
> >> example arch/x86/cpu/perf/ could probably move to arch/x86/events/,
> >> because that code is not about CPU events anymore either.
> >
> > All fine and dandy with me, but I'd prefer to do this after the merge
> > window, i.e. for 3.15. Rushing it now would just cause unnecessary
> > trouble IMO.
> >
>
> Oh, absolutely.
Agreed.
> > On Tue, Jan 14, 2014 at 05:22:03PM +0100, Ingo Molnar wrote:
> >> Absolutely. I think moving arch/x86/kernel/cpu/ to arch/x86/cpu/
> >> would be a first good step. It's all kernel code, there's other
> >> subdirectories there that are kernel code ('pci/', 'platform/', etc.),
> >> so there's little point in continuing the historic accident of a
> >> 'kernel/' subdirectory.
> >>
> >> Once that is done we can move certain things outside as well - for
> >> example arch/x86/cpu/perf/ could probably move to arch/x86/events/,
> >> because that code is not about CPU events anymore either.
> >
> > All fine and dandy with me, but I'd prefer to do this after the merge
> > window, i.e. for 3.15. Rushing it now would just cause unnecessary
> > trouble IMO.
> >
>
> Oh, absolutely.
Thanks,
Ingo
Borislav Petkov
Jan 14, 2014, 2:00:01 PM1/14/14
to
On Tue, Jan 14, 2014 at 08:10:28AM -0800, H. Peter Anvin wrote:
> Quite frankly I would be much happier if we didn't stash so much under
> arch/x86/kernel/cpu ... quite frankly it feels like almost *anything*
> could go under there. The microcode code, for example, could go under
> its own subtree.
Yeah, about the microcode, shouldn't it be under kernel/cpu/? My train
> Quite frankly I would be much happier if we didn't stash so much under
> arch/x86/kernel/cpu ... quite frankly it feels like almost *anything*
> could go under there. The microcode code, for example, could go under
> its own subtree.
of thought is: because it is cpu-related functionality, it logically
belongs there.
Or do we rather apply the shallow tree logic of
arch/x86/microcode
arch/x86/events
...
?
I have to say, arch/x86/kernel/cpu/ is kinda long and hard to remember
so the shallow structure should be nicer on the eyes and the brain :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
H. Peter Anvin
Jan 14, 2014, 2:20:02 PM1/14/14
to
On 01/14/2014 10:58 AM, Borislav Petkov wrote:
> On Tue, Jan 14, 2014 at 08:10:28AM -0800, H. Peter Anvin wrote:
>> Quite frankly I would be much happier if we didn't stash so much under
>> arch/x86/kernel/cpu ... quite frankly it feels like almost *anything*
>> could go under there. The microcode code, for example, could go under
>> its own subtree.
>
> Yeah, about the microcode, shouldn't it be under kernel/cpu/? My train
> of thought is: because it is cpu-related functionality, it logically
> belongs there.
arch/x86/cpu/microcode seems clean. I'm wondering if what is mostly
> On Tue, Jan 14, 2014 at 08:10:28AM -0800, H. Peter Anvin wrote:
>> Quite frankly I would be much happier if we didn't stash so much under
>> arch/x86/kernel/cpu ... quite frankly it feels like almost *anything*
>> could go under there. The microcode code, for example, could go under
>> its own subtree.
>
> Yeah, about the microcode, shouldn't it be under kernel/cpu/? My train
> of thought is: because it is cpu-related functionality, it logically
> belongs there.
currently in arch/x86/kernel/cpu should be mostly in something like
arch/x86/cpu/init.
-hpa
Borislav Petkov
Jan 14, 2014, 2:30:02 PM1/14/14
to
On Tue, Jan 14, 2014 at 11:18:57AM -0800, H. Peter Anvin wrote:
> arch/x86/cpu/microcode seems clean. I'm wondering if what is mostly
> currently in arch/x86/kernel/cpu should be mostly in something like
> arch/x86/cpu/init.
Yeah, I can start reorganizing stuff slowly and with time, the best
> arch/x86/cpu/microcode seems clean. I'm wondering if what is mostly
> currently in arch/x86/kernel/cpu should be mostly in something like
> arch/x86/cpu/init.
place will dawn on us. One thing's for sure, the "kernel" in the path is
kinda redundant because, as Ingo said, it is all kernel.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
H. Peter Anvin
Jan 14, 2014, 2:40:02 PM1/14/14
to
On 01/14/2014 11:27 AM, Borislav Petkov wrote:
> On Tue, Jan 14, 2014 at 11:18:57AM -0800, H. Peter Anvin wrote:
>> arch/x86/cpu/microcode seems clean. I'm wondering if what is mostly
>> currently in arch/x86/kernel/cpu should be mostly in something like
>> arch/x86/cpu/init.
>
> Yeah, I can start reorganizing stuff slowly and with time, the best
> place will dawn on us. One thing's for sure, the "kernel" in the path is
> kinda redundant because, as Ingo said, it is all kernel.
>
Indeed.
> On Tue, Jan 14, 2014 at 11:18:57AM -0800, H. Peter Anvin wrote:
>> arch/x86/cpu/microcode seems clean. I'm wondering if what is mostly
>> currently in arch/x86/kernel/cpu should be mostly in something like
>> arch/x86/cpu/init.
>
> Yeah, I can start reorganizing stuff slowly and with time, the best
> place will dawn on us. One thing's for sure, the "kernel" in the path is
> kinda redundant because, as Ingo said, it is all kernel.
>
-hpa
0 new messages