next up previous
Next: Resources available to dilute Up: Introduction Previous: Resource management in dedicated

So stuff it all into kernel space ?

There have been heated debates on kernel space applications - NFS moved into the kernel and HTTP accelerations. The general consensus for desk-top systems is leave it in user-space and only move as little as absolutely necessary into kernel-space. Even applications where the kernel approach could seem easy to justify like pppd moved almost everything to user-land and minimized the services in kernel space. So am I proposing kvi - the kernel editor to directly edit the kernels task list ? Not quite.

Dedicated embedded devices often include special drivers for the dedicated hardware, in many cases it is not sensible to introduce too many layers of abstraction which are justified if one assumes that a class of devices is to be introduced and the usefulness is not limited to a specific system setup. For embedded devices it is quite common that a device driver is totally useless even on a mildly modified system and/or multiple hardware entities are "hardwired" in software, something like a ISDN application/driver that logs to NVRAM. In such cases a lot of code moves into kernel space with the limitations of the kernel space API this can sometimes result in very strange code.

The problem with the split in kernel-space and user-space, under the assumption that user-space is trusted code, is that the kernel-space user-space (+ VFS) boundary is fairly expensive and for dedicated devices resource demands could be reduced if this boundary is diluted.
Last claim (for now):


next up previous
Next: Resources available to dilute Up: Introduction Previous: Resource management in dedicated
Der Herr Hofrat
2003-01-06