[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.018 / U:39.984 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site