[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Fpoll() in GEM programs
Hello!
Also I think Arnaud's proposal is even better than my with those magic pipe
creations (these are implementation detail).
Sorry, this is not just an implementation detail. It's the design itself
we discuss here. It's not a concept to say the process have some magic
pipe. The concept is who create the pipe, how it's visible, who manage the
resources and so on.
And if you think about this a bit more than you will find out that the AES
should be (XaAES is _only partially_ because it needs to use Bconin() due to
legacy ROM TOS routines usage and no proper /dev/keyboard, /dev/mouse,
/dev/whatever availability) built on top of Fselect()/Fpoll() loop as it is
FreeMiNT (UNIX) application. Note that I am not trying to criticize kernel
now, I am just trying to give you directions to think.
Then you maybe take a look into the sources first. Then you see that the
kernel module already use the keyboard device.
For mouse it's a different story. The current mouse input is a good
compromise against the much more important factor speed (the speed
factor is much, much more critical for mouse than for keyboard). As XaAES
also have original ATARI hardware in mind you can't use such expensive
synchronisation and scheduling mechanism like select and device I/O. Not
if you want a responsive AES system.
And I'm sure that all users of XaAES 0.96 who tested out the new kernel
module say that XaAES is a *lot* faster. But infact XaAES is just much,
much more responsible. And I'm sure you don't want to miss this too, even
if you can't use the UNIX file abstraction in this case.
It would be quite easy
to provide the filedescriptor (pipe, socket or whatever) for the application
signalled upon selected events.
Until know you only speak very vague about the descriptors. Please be
concrete about who create the descriptors, who own the descriptors,
how they are visible, how is access control organized, who manage the
resources and so on. This is not just implementation, this is the
(conrete) design. Implementation is to take the (concrete) design and to
write it down and test it. Implementation is not to take a very vague
design and to hack something down that may be the thing you want.
Ok, we are 2 (Standa, Arnaud) to 3 (Frank, Ozk, Henk). Please consider
cleaner extensions to those that could not last for long term. Konrad? Petr?
BTW: Ozk I think this is perfect time to speak about future extensions while
the implementation is in progress, because there doesn't need to be pause
after it is in the shape you consider n.aes equal. There will be another
extension designs ready by that time. ;)
Until know I only discussed about how it can be look like, there is no
parallel implementation from my side.
Regards,
Frank
--
ATARI FALCON 060 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de