Re: [GIT PULL] Protection Keys (pkeys) support
From: Linus Torvalds
Date: Sun Mar 20 2016 - 22:21:41 EST
So I finally got around to this one and the objtool pull request, and
note that there's a conflict in the arch/x86/Kconfig file.
And I'm not sending this email because the conflict would have been
hard to resolve - it was completely trivial. But the conflict does
show that once again people are starting to add the new options to the
end of the list, even though that list is supposedly sorted.
I didn't actually fix that up in the merge, because I think that those
options should be done differently anyway.
So all of these are under the "X86" config options as "select"
statements that are true for x86. However, all the new ones (and an
alarming number of old ones) aren't actually really "these are true
for x86". No, they are *conditionally* true for x86.
For example, if we were to sort those thing, the two PKEY-related
options would have to be split up:
select ARCH_USES_HIGH_VMA_FLAGS if
select ARCH_HAS_PKEYS if
which would actually make it really nasty to see that they are related.
There's also a *lot* of those X86 selects that are "if X86_64". So
they really aren't x86 options, they are x86-64 options.
So instead of having a _huge_ list of select statements under the X86
option, why aren't those split up, and the select statements are
closer to the thing that actually controls them.
I realize that for many *common* options that really are "this
architecture uses the generic XYZ feature", the current "select" model
is really good. But it's starting to look really quite nasty for some
of these more specialized options, and I really think it would be
better to move (for example) the select for ARCH_HAS_PKEYS and
ARCH_USES_HIGH_VMA_FLAGS to actually be under the
X86_INTEL_MEMORY_PROTECTION_KEYS config option, rather than try to lie
and make it look like this is somehow some "x86 feature". It's much
more specific than that.
Anyway, it's all merged in my tree, but is going through the built
tests and I'll do a boot test too before pushing out. So no need to do
anything wrt these pull requests, this was more of a "Hmm, I really
think the x86 Kconfig file is getting pretty nasty".