> If the patch were stripped down to just do the cpu detection, and leave
> the configuration up to set6x86 (except for enabling cpuid), would you
> object to that?
There seems little point. The extra code required to set up CPU
features is not particularly great. Furthermore changing performance
settings later when you have user processes up and running means
that other initializations which require repeatability, such as
udelay, are silently broken. The effects of such damage tends to
be obscure and insidious. Personally I prefer the overhead up
front where we can get it out of the way rather than the risk
of weird things happening to _some_ of the people _some_ of
the time.
Incidentally, the reason why all those wierd features are
config options is simply for testing. Ultimately the options
should be removed completely and the code should just do what
is right for the processor in use.
VSPM can actually be done outside the kernel - but you would
have to have set up traditional page tables to get far enough
to do it. The circumstances under which VSPM would show a
gain simply because of TLB effects are probably not easily
tested with any of the common performance measuring tools
around. You do however save a few pages of memory which
would otherwise have gone to kernel page tables :-). Since
only the 6x86-none-MX has VSPM it probably _should_ be optional,
if it is included at all.
Mike
-- .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 | | RG40 1XG, ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'