Using kernel_fpu_begin() in device driver - feasible or not?

Using kernel_fpu_begin() in device driver - feasible or not?

Post by Rickard Westma » Fri, 15 Feb 2002 09:20:12



Hi,

I am porting a device driver from an embedded platform where it's OK
to do floating-point arithmetic in drivers.  To make it easy to
incorporate future improvements from this "reference driver", I have
tried to keep my modifications at a minimum, with most Linux-specific
code clearly separated.  The heavy use of interspersed floating-point
arithmetic is an obstacle, though, as I'm aware of the policy to avoid
floating-point arithmetic in the Linux kernel.

Ideally, I'd like to use the FPU in a daemonized kernel thread created
by the driver, and possibly from process context as well (in the
implementation of some ioctl:s.)  The target architecture is i386, and
non-portable solutions are quite acceptable.

Now, I've noticed that there are two interesting-looking functions in
the 2.4 kernel: kernel_fpu_begin() and kernel_fpu_end().  I have found
little information on how to use them, though, and I'd appreciate any
hints and guidelines.  Here are some issues I'm concerned about:

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?

2. Would it be OK to go to sleep inside such a region, or should I
take care to avoid that?

3. Perhaps I should call init_fpu() at some point as well?  If so,
should it be done before or after kernel_fpu_begin()?

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)?

5. The functions mentioned above are not exported for use by loadable
modules, but I guess that could be arranged for.  Is there any other
reason why it shouldn't work from a loadable kernel module?

Suggestions on alternative approaches are welcome as well, of course,
but I *do* realize that I could replace the calculations with
fixed-point arithmetic, divide things so that all floating-point
calculations were done in user-space, and similar ways to dodge the
issue.  But for now, I'm just looking for feedback on how to actually
do it in kernel space, aesthetics aside...

--
Rickard Westman         "Beware of the panacea peddlers: Just

                          make you an emperor."
                                     - Michael A Padlipsky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Using kernel_fpu_begin() in device driver - feasible or not?

Post by Alan Co » Fri, 15 Feb 2002 23:10:12


Quote:> > kernel_fpu_begin()/kernel_fpu_end()?  If not, what problems could I
> > run into?

> You can do that providing you dont

Umm that wasn't me trying to be zen. I meant "you dont sleep"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. device driver using devfs on system with not mounted devfs

Hi all,

I've got a problem with a driver under a devfs-enabled kernel. The kernel
(2.4.16 SMP) is configured as:
CONFIG_DEVFS_FS=y
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set

Devfs is not mounted (and devfsd is not running). The driver is a char
device. I'm initializing the driver by calling:

handle = devfs_mk_dir(NULL,"mydriver",NULL);

I think I can use this handle to access all my devices even if devfs isn't
mounted and so this directory doesn't exits, right?

major = devfs_register_chrdev( 0, "mydriver", &mydriver_device_fops ))

I use this to get a dynamic major id for my driver.
After that I create some device nodes by calling

devfs_register(handle,name,MY_DEVFS_FLAGS,major,dev_cnt++,device_flags,&mydriver_device_fops,0)

in loop modifying name and dev_cnt in each iteration.

To unload the driver I'm just calling

devfs_unregister(handle)

At a first view this seems to work. But if I cat /proc/devices after that,
I'm getting a segmentation fault and /var/log/messages says:

Dec  7 16:20:41 nala kernel: Unable to handle kernel paging request at
virtual address d11adc82
Dec  7 16:20:41 nala kernel:  printing eip:
Dec  7 16:20:41 nala kernel: c02445ea
Dec  7 16:20:41 nala kernel: *pde = 0ff12067
Dec  7 16:20:41 nala kernel: *pte = 00000000
Dec  7 16:20:41 nala kernel: Oops: 0000
Dec  7 16:20:41 nala kernel: CPU:    0
Dec  7 16:20:41 nala kernel: EIP:    0010:[rwsem_wake+898/9524]    Not
tainted
Dec  7 16:20:41 nala kernel: EFLAGS: 00010297
Dec  7 16:20:41 nala kernel: eax: d11adc82   ebx: cdacf08a   ecx: d11adc82  
 edx: fffffffe
Dec  7 16:20:41 nala kernel: esi: cd78bf38   edi: ffffffff   ebp: d11adc82  
 esp: cd78bedc
Dec  7 16:20:41 nala kernel: ds: 0018   es: 0018   ss: 0018
Dec  7 16:20:41 nala kernel: Process cat (pid: 1606, stackpage=cd78b000)

On a devfs mounted system the driver seems to be ok. On Systems without
devfs it works too. So what I'm doing wrong? From my understanding the
procedure I've used should be ok. Or is there a _need_ to mount devfs if
its enabled in the kernel?

I've enabled some debugging options in the kernel:

CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_IOVIRT=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_BUGVERBOSE=y

Maybe there's a correlation between this options and the error above? Or
does anybody know about general problem with this kernel version?

Mathias

--

Tel.:  +49 621 181 2717  Fax.:  +49 621 181 2713

2. Can I do this with a script?

3. ? How do I find what device driver a device is using?

4. hOW TO INSTALL gcc

5. HELP needed: Solaris PCI device driver, device not auto detected.

6. wireless card install

7. Plug-ins not not seen by Gimp

8. ibcs broken in 2.4?

9. Device driver calling another device driver.

10. Device driver question (generic device driver)

11. Compare file modification date using tcsh built-ins

12. Stabbed US preacher flees INDIA state (The same INS tactics used against the stabbed preacher)

13. Plug-Ins using C++