From mint-bounce@lists.fishpool.fi Mon Mar 14 10:23:38 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <20050314031912.r4p1ykehn44googk@coolrunningconcepts.com> Date: Mon, 14 Mar 2005 03:19:12 -0600 From: evan@coolrunningconcepts.com To: mint@fishpool.com Subject: [MiNT] State of the Union MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [32001 32001] / [47 12] X-AntiAbuse: Sender Address Domain - coolrunningconcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: evan@coolrunningconcepts.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.8 tagged_above=-50.5 required=7.0 tests=BAYES_00, NO_REAL_NAME X-Spam-Level: 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