Prev: [PATCH 1/4] posix-timers: Refactoring of CPUCLOCK* macros
Next: x86, xsave: some code cleanups and reworks, -v2
From: Robert Richter on 27 Jul 2010 05:00
On 26.07.10 14:26:36, H. Peter Anvin wrote:

> >> I think it is cleaner to clear these cpu capabilities in the function
> >> which handles no387 boot parameter.
> >
> > This does not cover all (of course weird but potentially existing)
> > cases. Disabling xsave in the no387 setup would only work if an fpu
> > exists.
>
> If the fpu doesn't exist, then xsave can't exist, either.

It does not convince me to move it either to no387 setup or
xsave_init(). There is no benefit with both of it. We should disable
it where we decide to use the soft fpu. Otherwise we will not have the
same underlying rules for it. In case of xsave_init() we need to
duplicate fpu code and export it to xsave code. I want to avoid this
as xsave and fpu code should be kept simple and only be shared where
necessary.

-Robert

--
Advanced Micro Devices, Inc.
Operating System Research Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: [PATCH 1/4] posix-timers: Refactoring of CPUCLOCK* macros
Next: x86, xsave: some code cleanups and reworks, -v2