[lkml]   [1999]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: User vs. Kernel (was: To be smug, or not to be smug, that is , the question)

MOLNAR Ingo writes:
> [Jon M. Taylor writes]

>> * Lack of generalized message passing
> (RT-signals in Linux, a feature of Linux 2.2)

Could user acahalan send 42 bytes to user mmuscovi?
Even if that works, you have an ugly signal handler that
can't call many functions in libc. This is poor.

>> * Lack of a decent privilege/capability model
> (i guess you missed include/linux/capability.h, a feature of 2.2.
> Not completely finished, but the main mechanizm is in there.)

I believe he means "true" capability support. In any case,
Linux can't revoke normal user capabilities.

>> * Blocking I/O
> (whats your problem with that?)

This limits concurrency. Within the kernel, IO events need not be
serialized. User-space can only get this ability with threads.
Threads are quite a bit of overhead for such a simple need, plus
the use of threads tends to promote bugs.

Good solutions cover more than just IO.

>> * Interruptible system calls
> (what is your point here)

It is not good to return to userspace, loop around, and make the system
call a second time. The overhead and app code complexity are annoying.

>> * Process-based instead of interrupt-based
> (could you explain?)

Hmmm, there was a security concern mentioned. To me though, this looks
more like an implementation detail that would get in the way of
concurrent system calls.

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 13:49    [W:0.053 / U:10.820 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site