On Monday 12 October 2009 23:09:13 Jeff Epler wrote: > I suppose that since Michael Buesch beat me to the punch with something > that works, I should at least mention the work I had done towards > running emc on "realtime-linux". > > Michael's work adopts the "rtapi_app" concept of the userspace-only > simulator, but makes it work with the pthreads(?) library, which > together with a patched Linux kernel has promising latency but which > doesn't work with current hardware drivers.
Yeah, I think the concept actually is pretty good. Over the recent years I did some kernel development and I came to the conclusion that everything that _can_ be done in userspace _should_ be done in userspace. Reasons include that it's a hell of a lot easier to develop and debug. Bugs are less likely to trash the whole system. It works against stable ABIs and it doesn't require recompilation on slightly different kernels. There are a lot more reasons... So I think the basic concept of having a non-realtime rtapi-app and pthread based realtime threads that run the base thread, servo thread, etc is a pretty clean concept. > My work, which hasn't reached the stage of actually running rtapi/hal > code, keeps the kernel module-based approach of the current rtai port > by implementing rtai/rtapi-inspired threads and shared memory (the two > main facilities required by rtapi). The hoped-for advantage is that > hardware drivers would work without modification. Well, I think hardware driver modifications should not be that hard. I was most likely heading towards using the UIO framework, which permits writing full device drivers from userspace. If the device does not require servicing interrupts, it does not require a kernel module at all. In case of need for IRQ handling, the resulting kernel module is quite small and rather trivial. I did not use UIO yet, but I think it looks promising. Or look at the hal_parport port. It hardly touches the hal_parport code and just touches the parport hardware access layer. And the code added is trivial, IMO. And yet, it works on standard kernels without kernel modules and without raw I/O in userspace (which makes it a hell of a lot more portable). I think portability is also an issue which needs addressing in EMC. I think it would be very nice to run EMC on some embedded board with ARM or PowerPC CPU (Yes I know there are rtai ports, but they don't really work as well as the x86 port). So removing many x86 dependencies also is a key goal for me. -- Greetings, Michael. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
