[MiNT] State of the Union

[evan@coolrunningconcepts.com]

Hi guys,

A few short "where are we at" questions here:

Is Mintlib thread safe?  Is there a C library that is?  What else is required
other than some semaphore locking instead malloc(), free(), and similar
commands?

Mouse Wheels.  I saw some talk about it, and I have never really thought of a
mouse wheel as being anything other than buttons 4 and 5.  Most wheel mice even
click when you move the wheel.   The AES already supports lots of mouse buttons,
just because the button is rotary doesn't mean you should add more complexity
and add additional messages.   Can someone say API bloat?   If you want
automatic wheel support for older apps, perhaps you can hack the AES so that if
the application isnt waiting on the mouse buttons 4 or 5, and has a scroll bar,
then send scroll events instead.  Let the app tell the AES what sort of events
its looking for.

Now, I saw lots of Fpoll() in GEM.  Odd since I tried to get a discussion going
on this very same thing 11 years ago, and it seems I missed the discussion
about 4 months ago.  Was any final say made?  Has anyone looked at other APIs
for inspiration and ideas?  Glib contains an event loop, as does
wxWindows/wxWidgets and I would look at both of these, and maybe GnuSTEP as
well.  The problem has been presented quite clearly on this list.

Method 1 :  An enhanced evnt_multi().  The AES has to manage file descriptors,
but how?  It was select() yesterday, poll() today, and maybe epoll() or
kqueue() tomorrow!  What interface do you use to add a list of file handles to
evnt_multi() ?

Method 2 : An AES file handle, such as pipe.  I suppose there may be issues with
what to name the pipes and all this other stuff, but ... all that discussion is
reduced to a waste of bandwith with one word, "socket".   If the AES is a
server, that problem goes away.   There are other problems though.  Here, I
believe the issue is "what events do you want", and there may also be an issue
where the AES can't store the event if the application is sitting in Fselect()
and not event_multi() since event_multi() has the "place" to put the data, so
things get copied to a pipe or socket and then copied again to the evnt_multi()
params.   Making this efficient pretty much means getting as complicated as X
..see below.

Method 3 : Poll - short timeouts so we can waste time waking up an application
and doing some task switches and possibly screwing up caches and increasing our
housekeeping inside the kernel by having lots of timer events, just so we can
make another call and go right back to sleep again.  No thanks.

Method 4 : Thread - lets get a better thread library first.   I don't see trying
to send your parent an AES message to wake it up or sending it a signal to force
evnt_multi() to return as being clean or efficient.   Its only slightly better
than Method 3, and harder to debug.

That leaves us with 1 and 2 so far. So, we have 2 chicken and egg scenarios. 
And its actually, a bit deeper.  In X (equivalent of AES) everything runs in
user space, so it never actually sends the data right to the app.  Its getting
sent over a socket anyway as everything is done in user space for best
protection.  There was some discussion earlier about trying to somehow protect
the rest of the kernel from kernel modules like the AES and I think if you want
that sort of protection you must want a real Unix and X, not MiNT.  I like the
kernel approach for MiNT!  We're not trying to make yet another Unix clone. 
Unix will pass the data between apps while TOS will write it directly to the
application's memory.   This has some penalities in some cases, but for speed
and memory usage, MiNT takes the same approach that embedded systems do.  Unix
is going to make use of carefully tuned virtual memory systems, shared memory
regions, memory manager tricks, and finally end up copying the data from one
page to another.

Now, I think a pipe or socket would be bad as we don't really require the
network support of X, nor is the GUI in user space.  Another way is to have a
special device that could  use Fcntl() calls (or something of that sort) to
determine what types of events you are waiting for, and add and/or delete
events from the current "mask".   Now, you don't have to pass lots of stuff to
evnt_multi() for every call, just pass it once as an ioctl or whatever, and the
driver takes care of remembering what events you wanted, and can either remember
those events between reads, or you can set a "once only" flag so that you reset
the event list each time.  Drivers can also add and remove apps from the
run-queue and play with priorities and all sorts of kernel stuff.

Reading from the device reads the AES event and associated data.   In this case,
the device can actually store fairly detailed data, some per handle, and may not
have to store everything per-application (or per-handle), for example current
mouse position and such can simply be returned from the current state at the
time of the read.  You'd get a sort of "AES packet" you can read from the
device as a structure, and packed structure passing may become more common
anyways over using WORDs if we ever move to another CPU like the coldfire.

You could concievably wrap existing AES calls around such an interface, and I'm
really surprised that it wasn't set up that way to begin with when XaAES was
written.  When I heard that XaAES was in-kernel, I assumed an AES device to
read AES events from, and we would have never had this discussion at all.

Now, you can select(), poll(), or in the future, hopefully epoll() this device
and any other file descriptors you want.   In fact, the above was designed
somewhat from the basic design of epoll().

Now this differs slightly from the pipe model in that the kernel sends the data
directly to the application and doesn't put it into a temporary location like a
pipe, for less data copying.  Its a bit cleaner than a standard TOS approach,
but I don't believe this is less efficient than the current evnt_multi, and I
think it may actually be faster as you don't have to pass lots of data to
evnt_multi() all the time, just read the file descriptor again when data comes
in.  The old evnt_multi would actually be a blocking read on this device.

Now, I asked this same question 11 years ago.  Can one device open another in
MiNT?  Originally I asked for different reasons, but in this case the AES
device would have to open the mouse device and possibly others.

I do apologize for not having read the MiNT code in a very long time, and not
really looked at XaAES at all, but I will.   I just mainly wanted to see where
things where at and give my 2 cents ... err ... maybe 25 cents.  Sorry for the
long post.

-- Evan Langlois / CRC