From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Garnett To: Subject: Re: RTLinux workshop and EL/IX press coverage on EETimes Date: Wed, 22 Dec 1999 08:51:00 -0000 Message-id: References: <01d801bf4c95$b7938640$2f2782c2@cygnus.co.uk> X-SW-Source: 1999-q4/msg00009.html "Paul Beskeen" writes: > Just a quick news update and pointer. Cygnites Nick Garnett and Manfred > Hollstein recently attended the RTLinux workshop in Vienna and gave a > presentation on EL/IX. This kick-started discussions on use of the EL/IX API > within the RTLinux community and ongoing collaboration to try and ensure > that the EL/IX API spec meets their requirements. > > Enjoy, Paul. > > -- > Real-time Linux developers unite on API > > By Craig Matsumoto > EE Times > (12/20/99, 1:24 p.m. EDT) > > VIENNA, Austria - Developers of embedded-Linux systems established some > common ground at a gathering last week, as they laid the foundation to build > common threads among their various efforts and also decided to back Cygnus > Solutions' EL/IX as a common applications programming interface (API) for > embedded Linux. > > [...] > > See http://www.eet.com/story/OEG19991220S0029 for full story. > As a followup to this I would like to try and bootstrap some discussion on how we should improve/ammend/update the API spec to accomodate both real time Linux requirements as well as more general real time operating systems. Although "embedded" and "real time" are orthogonal, they often go together, so it makes sense to consider the latter at this point. The main problem with the current real time Linux implementations is that the real time portions of the application are separated from the non-realtime portions. Real time components are built into a kernel module while non-real time components go into a conventional process. The only communication allowed is via FIFOs and shared memory. While this may change in the future, the current restrictions will apply for some time to come. The main approach I want to take in handling this is to start by identifying a "real time" subset of the API. This would indicate those functions that can be expected to exhibit real time properties. For real time Linux these would be the functions that could be called in the real time module. For other operating systems these would be the functions that provide real time services, other functions would not be expected to be real time. A provisional list of the real time subset would consist of: POSIX pthread functions POSIX mutex and condition variables POSIX semaphore functions POSIX message queue functions At present there is no clear analog in the POSIX spec for the real time Linux FIFOs, although maybe they can be mapped onto message queues in some way. As far as the API is concerned, real time Linux programs would be modelled as two "processes" one containing the real time portion and one containing the non real time portion, connected by message queues and shared memory. These are just some initial ideas to try and get some discussion going, comments and criticisms to the list please. -- Nick Garnett mailto:nickg@cygnus.co.uk Cygnus Solutions, UK http://www.cygnus.co.uk