[lkml]   [2002]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Using kernel_fpu_begin() in device driver - feasible or not?
Alan Cox wrote:
> > 1. Would it be sufficient to just bracket all fpu-using code code by
> > kernel_fpu_begin()/kernel_fpu_end()? If not, what problems could I
> > run into?
> You can do that providing you dont
> > 2. Would it be OK to go to sleep inside such a region, or should I
> > take care to avoid that?
> You can't sleep in such a region - there is nowhere left to store the
> FPU context
> > 3. Perhaps I should call init_fpu() at some point as well? If so,
> > should it be done before or after kernel_fpu_begin()?
> After
> > 4. Is there any difference between doing this in the context of a user
> > process (implementation of an ioctl) compared to doing it in a
> > daemonized kernel thread (created by a loadable kernel module)?
> The kernel thread is actually easier, you can happily corrupt its user
> FPU context by sleeping since you are the only FPU user for the thread.
> Not nice, not portable but should work fine on x86 without any of the
> above for the moment.
> You should probably also test the FPU is present and handle it accordingly
> with polite messages not an oops 8)

So are kernel_fpu_begin()/kernel_fpu_end() (and also init_fpu()) necessary in a kernel thread at all
? Does kernel_fpu_begin()/kernel_fpu_end() take care of SSE and MMX registers too (I'm aware of the
extra "emms" needed in the MMX case) ?

Steffen Persvold | Scalable Linux Systems | Try out the world's best | | performing MPI implementation:
Tel: (+47) 2262 8950 | Olaf Helsets vei 6 | - ScaMPI 1.13.8 -
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY | >320MBytes/s and <4uS latency
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.064 / U:30.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site