[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