[lkml]   [2000]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Function calls not permitted in kernel code

[Mark James <>]
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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