* H. Peter Anvin <hpa@xxxxxxxxx> 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 <bp@xxxxxxx>
> > AuthorDate: Sun, 1 Dec 2013 18:09:58 +0100
> > Committer: Borislav Petkov <bp@xxxxxxx>
> > 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.
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.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|