Messages in this thread | | | From | Peter Samuelson <> | Date | Wed, 20 Sep 2000 20:41:13 -0500 (CDT) | Subject | Re: Function calls not permitted in kernel code |
| |
[Mark James <mrj@cs.usyd.edu.au>] > In summary: > > - Kernel code can't or shouldn't do anything too high-level.
In general, yes. This is why the winmodem driver people (last I heard) are trying to pull some of the modem functions out into userspace programs. Sync and cancellation algorithms for a phone line are too complex to trust to kernel space if you can help it.
Reasons are many. First, the kernel is too powerful: you can accidentally clobber arbitrary kernel memory, and rather than a segfault you'll end up with a system crash. There is no access control on resources so security must be maintained manually. Second, the kernel is harder to debug. Third, it is harder to replace (a userspace program is inherently easier to upgrade than even a kernel module).
> - A subset of libc functions is in the linux/lib directory. > Libc functions that mess with system things can't be used. > Utility functions can be used if the libc code is copied in.
Well, not "libc code" in most cases. The problem with libc (or most other libraries) is that it's designed for itself; that is, printf() requires the facilities of stdio which require the facilities of malloc() which requires the facilities of pthreads (or null pthreads emulation). So one function can easily pull in larger chunks of code.
But definitely if you need a C function that isn't already available you can write it yourself and compile it in.
> - Kernel code should get a user process to do the things it > can't do. The kernel and user procss can communicate using > either /proc, /dev, or system calls (netlink sockets look > like the go here).
Also note that if possible, you should make your userspace interfaces *reactive* rather than *active*. Example. You have a device to which you wish to download a firmware file off the filesystem. Do *not* have your driver spawn off a /sbin/mydriverfirmwareloader which reads the firmware file and feeds it back. Instead, wait for someone to open your device node (defer initializing the device until someone opens it for the first time), then have that program feed in the firmware at its leisure. The latter approach is more flexible and in most cases completely avoids the complexity of spawning userspace programs.
The relevant dictum is "policy belongs in userspace". How do you know your user wants to use a program called /sbin/mydriverfirmwareloader? You don't. If you just *react* to an open device, the userspace program can be called anything the user wants. `kmod', which *does* have to spawn a user program, actually creates a /proc file by which you can change the path to `/sbin/modprobe' -- just to avoid making policy in the kernel.
Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |