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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 14 Jan 2014 17:22:03 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, Aravind.Gopalakrishnan@....com,
	tglx@...utronix.de, bp@...e.de, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/microcode] x86, microcode: Move to a proper location


* H. Peter Anvin <hpa@...or.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 <bp@...e.de>
> > AuthorDate: Sun, 1 Dec 2013 18:09:58 +0100
> > Committer:  Borislav Petkov <bp@...e.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.

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-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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ