lkml.org 
[lkml]   [1997]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Some ideas
Date
> 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
too

Alan


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