Re: Exo-graphical systems (Was: [elysium-developers] PCT])

[Claus M. <cla...@ma...>]

> The basic philosophy behind exokernels, which has been discussed elsewhere
> on this site is here applied to user interface systems. This means that we
> have to apply the most important design principle of exo-kernels:
>
> * Multiplex resources of underlying systems without enforcing any
> abstractions that aren't strictly necessary for protection.
>
> In the kernel case the underlying system is the hardware.

I agree that this is a more precise description, and so I'll replace the
bit.

> The key thing to remember is that exo-systems are about not making any
> abstractions that aren't strictly necessary for protection. Traditional
> micro-kernels provide as few and as general abstractions as possible, but
> even though they are designed to be general there are several applications
> for which they fail miserably.
>
> * all privileged abstractions (necessary for protection) should be put in
> the kernel or privileged servers
> * all unprivileged, non-shared abstractions should be placed in libraries
> * some unprivileged, shared abstractions could be placed in unprivileged
> servers

Onco again I agree, but there is a point to be made here: As you correctly
write, only shared abstractions should be put in servers - unpriviledged
servers, of course, I never intended it otherwise. One key point I am trying
to make is, though, that abstractions are generally not shared *enough*.
Neither Gnome/X, Windows, BeOS can provide the flexibility we desire because
they cannot offer sound abstractions properly.

> I've got a thesis on 'Flexible and Efficient Sharing of Protected
> Abstractions' by George M. Candea, which explains how MIT has built shared
> abstractions on top of their exokernel without using unprivileged servers.

I would of course like to read it - but I am not principally against
servers, and think they often provide a good abstraction. We should of have
more than absolutely necessary, but I fear that avoiding them completely
could make things messy. After all, a user would be quite contend to lose
3-5% processing power in exchange for at 20% increase in his own work
efficiency. Still, I would be glad to read it.

> As an aside it should be noted that there are advantages - at least one -
of
> putting abstractions into servers (instead of tossing them into
libraries).
> Servers allow for higher levels of distribution. OTOH it might be too
slow.

Precisely my point. I am quite willing to sacrifice a small performance loss
for programs using servers. I think the design of the server structure
should follow the general outline of a display server, though; No server
should enforce standards by checking all operations on, for example, paper.
They should instead try to check things only when it is their concern - for
instance when something is commited in some way. If the server is only
invoked once every 5 seconds, the performance loss is miniscule.
Combinations of libraries and servers are also an option.

And now for Adam's comment:

> You have some great ideas on graphical handling,

Well, thanks! :-)

> but I must contest this point.

Oh, shoot. :-(

> I assume elysium is going to be a proper O/S, with multiple users as in
*NIX.
> I don't want the kernel to have to know anything about users, and enforce
> permissions, I see some logon process taking a username&passwd and then
> spawning a shell with the correct capabilities for that 'user'.

>Now if we have many processes, with differing permissions we *cannot* allow
>the keyboard data to be sent to all of them. For example, if someone is
telneted
>onto the same box as me, they could run a program that saves all keystokes
>(because we "distribute keyboard commands to all processes that request
it")
>and he could capture my GPG passphrase etc, as I type it. This is not a
>solution.

> The problem is that the kernel doesn't know anything about 'focus'. Also
many
> processes can have 'focus', because there can be many keyboards. Only one
> wired to the box, but many over a network.

> We could have a keyboard server that sends the data on to the correct
process,
> but if there are keyboards over a network, this means that it must handle
> network data too. This means lots of abstractions.

> I can't really think of a good solution at the moment. Anyone?

You are quite right. Once again I turn to my server architecture (look, i'ts
not that I love servers. They're just so d*mn handy sometimes). The keyboard
server descides which process has the focus when the system starts - the
login process, for instance. The login process does not "talk" to the
keyboard via the server, it does so directly. When this process has finished
(the keyboard server can just be programmed to let it have keyboard Focus
until the login is satisfied), the next keyboard lending process gets the
Focus. This could be a fancy keyboard server with country codes, perhaps
even with code that allows they keyboard input to be sent directly via the
network. Once again, the priviledged servers does not, like normal servers,
run constantly - they are only invoked whenever Focus has to change,
something that happens rarely, even in human time spaces.

That's my best bid for the moment. Comments are, as always, welcome.

- xmentor