[lkml]   [1997]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Some ideas
    > 2. While we're here, how about using constructor/destructor functions
    > instead of `init_module' and `cleanup_module'?

    Why break compatibility with something that works well. If it bugs you for
    a given module make init_module a hook to the constructors

    > shared library such that it runs either (a) with special privileges
    > (e.g., as "root"), or (b) in kernel space. In both cases, the idea
    > is that it is callable from user space just like a normal shared
    > library, but the calls to the kernel/privileged part are fixed up to
    > jump through a call gate or syscall to do the privilege switch. (And
    > so are the returns).

    It gets quite slow doing this, and on esome CPU's the flexibility to do
    these kind of tricks is limited. (Its not BTW a new idea - its very close
    to how Apollo Domain/OS worked)

    > * Remove the need for many ioctls, replacing them with typed
    > function calls.

    Unix is specifically designed NOT to have this huge sprawling messy API.
    You can build API's as you like

    > are other examples. Programs that need limited guarantees on
    > real time performance, or limited page locking capabilities
    > spring to mind. There is no need to give these programs full
    > root privileges.

    This is really a POSIX priviledges/rights issue. There are drafts for
    this sort of stuff

    > things, because sometimes (such as libvga or XF86DGA) the
    > unprivileges thread needs direct access to some device-mapped memory
    > that only the privileged thread set up. You can set everything up at

    You get priviledges at open time. This is very much a feature. Thus I can
    open a device and pass you the handle for you to do mmap() calls on even
    if I call you unpriviledged.

    > characters while /dev/kbdN is open. Then if a program using raw
    > keyboard mode crashes, the keyboard is fine and you don't have to
    > reset your computer or have a handy other computer on a nearby
    > network.

    GGI should also be addressing this issue. WHen you have GGI you have SACK
    (not to be confused with the networking SACK). That means you can hit a
    chosen key combination in any situation and know all processes on the tty
    where killed and you get back a clean login. It has good security advantages


     \ /
      Last update: 2005-03-22 13:39    [W:0.020 / U:6.840 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site