From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Thu, 19 Aug 1999 10:35:06 +0200 (MET DST)

Re: VC Switching

Hi !

> >Imagine if an X server emulated the text consoles (and there's no
> >reason why it couldn't AFAIK).  It would be indistinguishable from the
> >current system.  I'm not advocating that BTW :->, but I think it
> >points the way to how it *should* be done.

> So lets see if I understand this correctly.

> You want to be replace a system that has the kernel moving a few K
> around at a time with one where a multi-meg user process has to move
> multi-meg graphic images around, because the kernel shouldn't
> be doing UI?

No. What he is suggesting is basically, that there should be a "server process"
that arbitrates access to the screen. This is basically what one would do on 
a microkernel, and thus IMHO a good thing, but not very probable to happen 
under Linux.

I actually am a fan of the microkernel approach, as it makes stuff more 
flexible, and I don't give a damn about 1% more overhead, as if I really
want that 1%, I can overclock my CPU by this amount.

> Do you want the userspace to be responsible for drawing tabs? For
> handling ctrl-U (ctrl-X for some) line erasing?

Yes and no. What he is saying is, that acces to graphics and text modes 
should be arbitrated by a single common instance. It doesn't matter much, if
it runs userspace or kernelspace or even "serverspace", as one would maybe
call it on a microkernelish design.

The idea is only to arbitrate access, not to draw on behalf of the application.

> The point is: The kernel's job is to give you abstractions. Whether

Yes. It is the question of where exactly to put the abstraction, and where 
to draw the line between kernel stuff and userspace stuff. 
Linux is already using userspace progs to do kernel stuff like NFS,
loading modules and such.

It is a question of how much microkernel one wants to introduce.

CU, Andy

-- 
Andreas Beck              |  Email :  <Andreas.Beck@ggi-project.org>