Re: Supervisor mode & multitasking

[Konrad Kokoszkiewicz <draco@piwo.bl.pg.gda.pl>]

> > - GEM should run as root. BTW. I'd like to have an AES daemon, which
> >   activates only if a graphical shell (like Thing) is started.
> > - GEM starts the shell (desktop). The desktop is also root.
> > - the desktop executes some sort of GEM login, then switches uid/gid
> >   to the selected one.
> > 
> > So I think it might be useful to incorporate login code to Thing desktop
> > (displaying MODAL dialog box at the beginning).
> 
> You should look at GEM-Init, which does this already.

GEM init yes. But there's a serious problem with it. GEM-init is started 
by the AES as a shell, then it starts the true shell once someone has
logged on. As a result, the desktop is not treated by the AES as a shell,
but as a normal application. Thus, when you run a program, "real" desktop
(i.e. login) gets topped by the N.AES and Thing's desktop window, with
background image, icons etc, disappears replaced by grey thing of N.Desk.
It looks _very_ ugly.

A perfect solution would be to start GEM login before shell, but it has to
be done inside the N.AES. At least, when the desktop would contain a
login, there would be no way to log out. :)

> > This way we can avoid rewriting the whole GEM for multiuser, just to fix
> > the desktop. The question is, what to do with XBIOS. Shall be local user
> > allowed to use it (for playing mp2 for example)?
> 
> I guess it would be sensible to allow only root to access XBIOS (but I
> have not looked into this in any detail).

Uhm, I thought so too. Restrict XBIOS to root, then put some of its
functions (like all DSP calls) to the /dev as separate device (/dev/dsp).

Konrad M.Kokoszkiewicz
mail:draco@bl.pg.gda.pl
http://www.orient.uw.edu.pl/~conradus/

** Quem Iuppiter vult perdere, dementat prius.
*******************************************************
** Kogo Jowisz chce zgubic, temu wpierw rozum odbiera.