Re: [MiNT] AES in kernel (was: XaAES / GEM memory issues)

[Guido.Flohr@t-online.de (Guido Flohr)]

On Mon, Jan 08, 2001 at 08:47:53PM +0100, Frank Naumann wrote:
> Hello!
> 
> > > No, don't. So far we have a kernel which is less or more independent of a
> > > gui, and no type of a gui is favourized. While the AES gets intergrated
> > > into the kernel we:
> >
> > I think Frank was being ironic (or sarcastic, if you will), in
> > response to Sven's ideas. :)
> 
> Not at all :-) But I wasn't exactly enough to cleary state my opinion.

Here is my point of view:

The AES and VDI are much more an integral part of all Atari operating
systems than GUI engines on other systems.  Unfortunately (I consider that
ill-designed) the AES and VDI take over a lot of functionality that should
be completely under kernel control:

- A proprietary messaging system
- Low-level i/o with hardware devices like mouse and keyboard
- Interrupt administration (mouse, joystick vector ...)
- Task scheduling
- ...

This is already bad enough, we don't need any more of this.

On the other hand, GEM is not designed to run as a normal application like
for instance a window manager with X11, and does all hardware
communication via device drivers.  However, MiNT should at least
theoratically allow such an approach.  Ralph's X-Server relies on GEM, but
you could also think of a standalone X-Server (or whatever).  The kernel
design should not be an obstacle for such a project.

There is already a way of integrating the AES, maybe even the VDI into the
kernel.  Why not simply realize it as a device driver?  If GEM really has
to bend vectors etc. then, as a device driver, it could at communicate
with the kernel on a low level, with little overhead, neatly integrated in
the system.

Such a device-driver GEM could also much better server "both
worlds".  Traditional GEM programs would still trap into AES/VDI, more
advanced applications could benefit from the new design:  Take for example
a graphical web browser that wants to select i/o from a handful of sockets
and still wants to poll the mouse, keyboard and the AES message
queue.  Currently you need two event queues for that: One for the AES
(evnt_multi) and one for i/o (poll/select).  If the AES provided devices
for all that, it could be done all in one loop (and it is also a very
natural view to treat i/o on a file descriptor and a mouse movement
event equally in terms of program flow).  Instead, currently you either
have to use the crippled thread approach which causes a lot of overhead
inside the application in order to synchronize the threads, or you fire
zillions of useless requests (evnt_timer and poll/select) into the
system.  BTW, each request will also cause a context switch.  And what, if
some lunatic will ever dream of a virtual Java machine in that
browser?  Yet another model that wants to be served ...

Another example is Ralph's X-Server.  It uses the underlying GEM, that's
fine because it allows users to integrate GEM and X very closely.  But it
still has to listen on the network (or files associated with shared
memory) for incoming requests and has to wait for output buffers to become
empty.  I think it would be much easier to simply wait on one single queue
and poll all devices with one single system call.

The new i/o based GEM API would also be free to be designed in a more
modern way, for example with better extendable OBJECTs, better mouse
support (generic mouse move events, three-button or wheeel support
...).  Again the X server: The AES handles the rectangle lists for the
OBJECTs, Ralph has to handle his (derived) rectangle lists for his frames
(or widgets or however this is called in the X protocol).  A lot of
overhead could be saved if there were functions that would allow programs
like the X server to let GEM do that in one go.  I am sure that in the
combination N.AES and X a lot of calculations are performed twice, simply
because there is no way to exchange the information that is needed.

Just my opinion on the topic. ;-)

Ciao

Guido