On 2018-10-12 11:07:28 [-0700], Andy Lutomirski wrote:
> All these "if" statements in the FPU code are messy and make
> understanding and reviewing this code hard.
>
> Can you prepare a patch for the beginning of your series that removes
> fpu->initialized and just ensures that the fpu is always
On 2018-10-12 11:07:28 [-0700], Andy Lutomirski wrote:
> All these "if" statements in the FPU code are messy and make
> understanding and reviewing this code hard.
>
> Can you prepare a patch for the beginning of your series that removes
> fpu->initialized and just ensures that the fpu is always
On Fri, Oct 12, 2018 at 10:58 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The fpu->initialized flag should not be changed underneath us. This might
> > be a
> > fallout during the removal of the LazyFPU support. The FPU is marked
> > initialized as soon
On Fri, Oct 12, 2018 at 10:58 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The fpu->initialized flag should not be changed underneath us. This might
> > be a
> > fallout during the removal of the LazyFPU support. The FPU is marked
> > initialized as soon
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The fpu->initialized flag should not be changed underneath us. This might be a
> fallout during the removal of the LazyFPU support. The FPU is marked
> initialized as soon as the state has been set to an initial value. It does not
> signal
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The fpu->initialized flag should not be changed underneath us. This might be a
> fallout during the removal of the LazyFPU support. The FPU is marked
> initialized as soon as the state has been set to an initial value. It does not
> signal
6 matches
Mail list logo
