[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] kqueue() vs. gemdos xdd
Hello!
about the typical case of 1 AES file descriptor, possibly while loading
What is an AES file descriptor?
Secondly, its unclear how well the AES would fit into the kqueue()
As kqueue is an event notification mechanism, every thing that generates
events fit into kqueue.
If you use a xdd with Fcntl/Fread/Fwrite you can for sure reach the same.
But it's more complicate to handle (the interface is designe for I/O and
not events). Also such extension for the AES is specific for the AES.
I'm sure you need to implement a similiar event management as for
kqueue, just specific for the AES.
mechanism. For example, take evnt_multi() ... how do you pass in and
out all that information?
evnt_multi() don't pass in/out much information. Just a lot of pointers
where the AES read/write the information.
Third, it seems like a big piece of code. I haven't looked to see how
many places in the kernel it would touch, but it seems like it could be
The good thing is you don't need to start with an all-in-one solution. You
can go step by step. As already mentioned the kqueue mechanism is very
flexible and easily extensible. You can add new events at any time later.
No need to start with all sort of events. We can try out with some events
and if it work good we can complete it stepp by step.
The AES knows which application it wants to send an event to, so it
would just be a matter of sending the data to the right fd (and by
reading the event with Fread() we can attach quite a bit of data to the
event, possibly precede the data by the size of the event data to be
read).
The user space code will be a funny thing as you need to type the data and
the application need to be prepared to interpret these typed data. Writing
such things tend to be error-prone as it's hard to for application
developers to understand the needs to write robust, tolerant code. If you
ever get a synchronization error the application is lost.
Also the implementation inside the kernel is complicated as you need to
buffer, need to be prepared if the buffer run out of space and so on.
Making trap #2 a wrapper around either GEMDOS calls or around Kqueue()
is a separate issue, and I think there would be a benefit to making both
old and new APIs have the same kernel entry points and go through the
same code paths. It shouldn't be all that intensive to do either
providing the equivalent "new" method of performing the same operation
is well documented.
The current XaAES module already enter the kernel in the same way as the
GEMDOS. It's just another trap number.
Regards,
Frank
--
ATARI FALCON 060 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de