Re: [MiNT] Fpoll() in GEM programs

[Philipp Donzé <philipp.donze@epfl.ch>]

Hi,

Here are some comments from me:

TOS is layered like this:
-(X)BIOS is the lowest level which implements various hardware 
dependant stuff.
-GEMDOS is built on (X)BIOS calls and implements the file handling.
-VDI is based on GEMDOS and (X)BIOS for providing a "virtual device" 
abstraction for text, lines, bitmaps,...
-AES is built onto VDI and GEMDOS. (I don't think it cares about the 
existence of (X)BIOS.)

As a general rule, you can see that the lower layers don't know 
anything about the upper layers (e.g. GEMDOS dosn't know anything about 
AES or VDI). The lower layers provide services to upper levels. In 
other words: the upper layers depend (!) on the existence of the lower 
layers.

MiNT is special: It's GEMDOS implementation relies on it's own "kernel 
modules" (?) and avoids as much as possible the (X)BIOS stuff.

Now taking a closer look at your proposal:

> int aes_fd = get aes_fd somehow
> loop {
>    select( input_fds | aes_fd, 0 );
>    if ( aes )
>       event_multi_fast( 3 arguments );
>    if ( action )
>       do_action();
> }
> do some cleanup here

select() is a function based on mintlib. In the background it calls 
probably the GEMDOS call "Fselect()". So we can clasify select() as a 
GEMDOS call. And as it reads from a file descriptor, it seems clean and 
doesn't "mix up" the layered OS model.
But the big problem is the "magic" you do to get this file descriptor: 
somehow an AES call returns a filedescriptor to a pseudo file/pipe 
which is owned by the AES. It's part of AES because it exists only if 
AES is present! But to provide such a pseudo file/pipe, the AES has to 
be part of GEMDOS or a "filesystem module" of GEMDOS, i.e. AES provides 
services to GEMDOS for creating/accessing/deleting this file 
descriptor.
=> Mix up of the layer system.

OK, you can argue that the pseudo file/pipe management is not 
necessarily provided by the AES itsself but by a "pseudo filesystem 
module". But also in this case, the pseudo filesystem has to know of 
the existence of the AES and it should only provide the pseudo 
file/pipe for AES applications.
=> You still have a dependence pointing from a lower layer to an upper 
layer.

Such an approach is considered as inproper and problematic.


IMO Franks approach is "the proper" solution:
> Your proposal was something like this:
> loop {
>   whatever_multi( MU_* | MU_SELECT [| MU_POLL][| MU_whatever we
>                   find later], hundreds of arguments );
>   if ( MU_* )
>      ...
> }

As the AES has knowledge of the existence of GEMDOS (and therefor of 
Fselect()) it can provide a system call which provides a similar 
service as Fselect() in the GEMDOS layer.
In a OS developer point of view, this is the proper way to go!

I think your only argument against this approach is efficiency, as 
there are "hundreds of arguments" to pass.
But at the moment we have no knowledge about the implementation. So we 
can't tell if this argument passing is a problem.


regards
Philipp