* RTLinux workshop and EL/IX press coverage on EETimes @ 1999-12-22 8:02 Paul Beskeen 1999-12-22 8:21 ` Stuart Hughes 1999-12-22 8:51 ` Nick Garnett 0 siblings, 2 replies; 9+ messages in thread From: Paul Beskeen @ 1999-12-22 8:02 UTC (permalink / raw) To: elix 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTLinux workshop and EL/IX press coverage on EETimes 1999-12-22 8:02 RTLinux workshop and EL/IX press coverage on EETimes Paul Beskeen @ 1999-12-22 8:21 ` Stuart Hughes 1999-12-22 8:51 ` Nick Garnett 1 sibling, 0 replies; 9+ messages in thread From: Stuart Hughes @ 1999-12-22 8:21 UTC (permalink / raw) To: Paul Beskeen; +Cc: elix Paul Beskeen wrote: > > 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. > Indeed, the RealTime Linux workshop was a great success, and Cynus's involvement was warmly appreciated. Zentropix has been an advocate of the EL/IX initiative from the beginning, and as the principal RealTime Linux company, we look forward to work with all the supporters of EL/IX and the RealTime Linux community to ensure its adoption for the RealTime Linux standards based API. Regards, Stuart -- Visit http://www.zentropix.com/ for Real Time Linux Tools Visit http://www.realtimelinux.org/ for more info about Linux and RealTime ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTLinux workshop and EL/IX press coverage on EETimes 1999-12-22 8:02 RTLinux workshop and EL/IX press coverage on EETimes Paul Beskeen 1999-12-22 8:21 ` Stuart Hughes @ 1999-12-22 8:51 ` Nick Garnett 1999-12-22 9:20 ` Mark Johannes 1999-12-22 9:56 ` Stuart Hughes 1 sibling, 2 replies; 9+ messages in thread From: Nick Garnett @ 1999-12-22 8:51 UTC (permalink / raw) To: elix "Paul Beskeen" <paulb@cygnus.co.uk> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTLinux workshop and EL/IX press coverage on EETimes 1999-12-22 8:51 ` Nick Garnett @ 1999-12-22 9:20 ` Mark Johannes 1999-12-22 10:16 ` Nick Garnett 1999-12-22 9:56 ` Stuart Hughes 1 sibling, 1 reply; 9+ messages in thread From: Mark Johannes @ 1999-12-22 9:20 UTC (permalink / raw) To: EL/IX Nick and All, I would like to suggest the POSIX.13 Realtime Profiles as a place to look for help in determining the realtime as opposed to the non-realtime. In fact, if the group can formulate another profile, perhaps this should be brought to the PASC commitee. In the case that POSIX does not meet our needs, we should standardize these calls (such as interrupts, etc...) and work to see their incorporation into the POSIX specifications. We at OAR are very excited about this new API and wish to provide our assistance with its definition. Our typical domain is in the deeply embedded and we have accumulated a vast knowledge base on how an operating system is to play within these confines. We also realize that this operating system must "connect" to the world through standards and other OSs such as standard Linux, NT and others. An open standard allows for the PNP that everybody wishes. Regards, Mark Johannes OAR Corporation Nick Garnett wrote: > "Paul Beskeen" <paulb@cygnus.co.uk> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTLinux workshop and EL/IX press coverage on EETimes 1999-12-22 9:20 ` Mark Johannes @ 1999-12-22 10:16 ` Nick Garnett 0 siblings, 0 replies; 9+ messages in thread From: Nick Garnett @ 1999-12-22 10:16 UTC (permalink / raw) To: Mark Johannes; +Cc: EL/IX Mark Johannes <mark.johannes@oarcorp.com> writes: > Nick and All, > > I would like to suggest the POSIX.13 Realtime Profiles as a place to look for help > in determining the realtime as opposed to the non-realtime. In fact, if the group > can formulate another profile, perhaps this should be brought to the PASC > commitee. In the case that POSIX does not meet our needs, we should standardize > these calls (such as interrupts, etc...) and work to see their incorporation into > the POSIX specifications. Yes, the POSIX profile needs to be looked at and included somehow. When I get a copy I'll work on this. -- Nick Garnett mailto:nickg@cygnus.co.uk Cygnus Solutions, UK http://www.cygnus.co.uk ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTLinux workshop and EL/IX press coverage on EETimes 1999-12-22 8:51 ` Nick Garnett 1999-12-22 9:20 ` Mark Johannes @ 1999-12-22 9:56 ` Stuart Hughes 1999-12-22 10:26 ` Nick Garnett 1 sibling, 1 reply; 9+ messages in thread From: Stuart Hughes @ 1999-12-22 9:56 UTC (permalink / raw) To: Nick Garnett; +Cc: elix Nick Garnett wrote: > > 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. Hi Nick, Thanks for your analysis, which is spot on. So far RTAI has support for: POSIX pthread functions POSIX mutex and condition variables We have just submitted a POSIX queues module for inclusion in RTAI. This leaves semaphores, which are available but not using the standard POSIX API. I think that it should be possible to provide a wrapper to support this API. Regarding the communications between the RT kernel and regular user space processes, what you say is correct, however there is also a mailbox mechanism for IPC communication. Also we are looking at a method of providing transparent access at the API level to the standard kernel syscalls, this would mean that for realtime tasks they would then be running at kernel priority rather than being true realtime tasks. If this is possible I think it is attractive, as from a programming point of view you wouldn't have the extra overhead of worrying about communication with the Linux system proper. Another problem that needs to be addressed is how to support the periodic nature of tasks, that is the norm in RealTime tasks. Our first thoughts are to provide a POSIX timers/clocks module. For example, one possibility is to make use of the pthreads notification mechanism SIGEV_THREAD this would allow a pthread to block on a condition variable which is signaled by a POSIX timer expiring. This is just one route and I would be glad to hear if anyone has thoughts on this. Regards, Stuart ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTLinux workshop and EL/IX press coverage on EETimes 1999-12-22 9:56 ` Stuart Hughes @ 1999-12-22 10:26 ` Nick Garnett 1999-12-23 3:39 ` Stuart Hughes 0 siblings, 1 reply; 9+ messages in thread From: Nick Garnett @ 1999-12-22 10:26 UTC (permalink / raw) To: Stuart Hughes; +Cc: elix Stuart Hughes <sehughes@zentropix.com> writes: > Hi Nick, > > Thanks for your analysis, which is spot on. So far RTAI has support > for: > > POSIX pthread functions > POSIX mutex and condition variables > > We have just submitted a POSIX queues module for inclusion in RTAI. That's good. The more standardized moduled we have, the less effort it will be to get the real time Linux users to adopt the API. > > This leaves semaphores, which are available but not using the standard > POSIX API. I think that it should be possible to provide a wrapper to > support this API. This is what I had understood from the workshop. I guess that the work to get this into a POSIX API with the correct semantics should not be too hard. > > Regarding the communications between the RT kernel and regular user > space processes, what you say is correct, however there is also a > mailbox mechanism for IPC communication. Also we are looking at a > method of providing transparent access at the API level to the standard > kernel syscalls, this would mean that for realtime tasks they would then > be running at kernel priority rather than being true realtime tasks. If > this is possible I think it is attractive, as from a programming point > of view you wouldn't have the extra overhead of worrying about > communication with the Linux system proper. I had missed the mailbox mechanism. Being able to call standard kernel functions from the real time module would make use of the API a lot easier, although there would still be the issue of C library functions to consider. Also, since an RT thread would presumably cease to be real time while calling a kernel function, it is important to indicate these in the API spec. > > Another problem that needs to be addressed is how to support the > periodic nature of tasks, that is the norm in RealTime tasks. Our first > thoughts are to provide a POSIX timers/clocks module. For example, one > possibility is to make use of the pthreads notification mechanism > SIGEV_THREAD this would allow a pthread to block on a condition variable > which is signaled by a POSIX timer expiring. This is just one route and > I would be glad to hear if anyone has thoughts on this. > Yes, I was worried about how to handle the "go periodic" stuff. This seems like a promising solution. I believe that there is also some work going on to extend the POSIX API and interfaces to cope with schedulers other than the standard set. However, I do not know anything about this. -- Nick Garnett mailto:nickg@cygnus.co.uk Cygnus Solutions, UK http://www.cygnus.co.uk ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTLinux workshop and EL/IX press coverage on EETimes 1999-12-22 10:26 ` Nick Garnett @ 1999-12-23 3:39 ` Stuart Hughes 1999-12-23 4:23 ` Nick Garnett 0 siblings, 1 reply; 9+ messages in thread From: Stuart Hughes @ 1999-12-23 3:39 UTC (permalink / raw) To: Nick Garnett; +Cc: elix Nick Garnett wrote: > > Stuart Hughes <sehughes@zentropix.com> writes: > > > This leaves semaphores, which are available but not using the standard > > POSIX API. I think that it should be possible to provide a wrapper to > > support this API. > > This is what I had understood from the workshop. I guess that the work > to get this into a POSIX API with the correct semantics should not be > too hard. I agree, it shouldn't be too difficult. > > > > > Regarding the communications between the RT kernel and regular user > > space processes, what you say is correct, however there is also a > > mailbox mechanism for IPC communication. Also we are looking at a > > method of providing transparent access at the API level to the standard > > kernel syscalls, this would mean that for realtime tasks they would then > > be running at kernel priority rather than being true realtime tasks. If > > this is possible I think it is attractive, as from a programming point > > of view you wouldn't have the extra overhead of worrying about > > communication with the Linux system proper. > > I had missed the mailbox mechanism. Being able to call standard kernel > functions from the real time module would make use of the API a lot > easier, although there would still be the issue of C library functions > to consider. Also, since an RT thread would presumably cease to be > real time while calling a kernel function, it is important to indicate > these in the API spec. > You're right, if a realtime task made a call to a Linux kernel service, is not longer running at a realtime priority and this would need to be made very clear. One of the ideas we had was to reserve a group of priorities that would be 'kernel priority', and say that any RT task calling these services must run at kernel priority, to enforce this we would need some checking (maybe simply forcing the need to link to a library). At the moment, this is only an idea, but I would love to see some kind of transparent access to the Linux kernel from RT to make the programmer feel that he/she is developing in a coherent environment. As you mention, the C library is also a problem and there is a need for (and we have been exploring) a libc_rt.a library. Already some brave people have been linking in some of the static libraries into their applications (libm.a is common). Generally this works, but at the end of that day you need to know what you are letting yourself in for. BTW Nick, can you let me have another e-mail address for you (nickg@cygnus.co.uk has been bouncing). Regards, Stuart. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: RTLinux workshop and EL/IX press coverage on EETimes 1999-12-23 3:39 ` Stuart Hughes @ 1999-12-23 4:23 ` Nick Garnett 0 siblings, 0 replies; 9+ messages in thread From: Nick Garnett @ 1999-12-23 4:23 UTC (permalink / raw) To: Stuart Hughes; +Cc: elix Stuart Hughes <sehughes@zentropix.com> writes: > You're right, if a realtime task made a call to a Linux kernel service, > is not longer running at a realtime priority and this would need to be > made very clear. One of the ideas we had was to reserve a group of > priorities that would be 'kernel priority', and say that any RT task > calling these services must run at kernel priority, to enforce this we > would need some checking (maybe simply forcing the need to link to a > library). At the moment, this is only an idea, but I would love to see > some kind of transparent access to the Linux kernel from RT to make the > programmer feel that he/she is developing in a coherent environment. > I think this is important. The "two level" model that currently exists is, as someone on /. said yesterday, a bit of a hack. The more that can be done to produce a single seamless programmer model the better. > As you mention, the C library is also a problem and there is a need for > (and we have been exploring) a libc_rt.a library. Already some brave > people have been linking in some of the static libraries into their > applications (libm.a is common). Generally this works, but at the end > of that day you need to know what you are letting yourself in for. > > BTW Nick, can you let me have another e-mail address for you > (nickg@cygnus.co.uk has been bouncing). > Really? That is my canonical address and should work. You can try nickg@cygnus.com, but that is really just a forward to my .uk address. It may be that you are accidentally being zapped by out spam filter. I have just talked to our sysadmin and that is exactly what is happening. It appears that your IP address is in a range that someone sometime decided we didn't like. Probably as a result of spam from another user of your ISP. It should be fixed now. If you get any more bounces, let me know. -- Nick Garnett mailto:nickg@cygnus.co.uk Cygnus Solutions, UK http://www.cygnus.co.uk ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-12-23 4:23 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-12-22 8:02 RTLinux workshop and EL/IX press coverage on EETimes Paul Beskeen 1999-12-22 8:21 ` Stuart Hughes 1999-12-22 8:51 ` Nick Garnett 1999-12-22 9:20 ` Mark Johannes 1999-12-22 10:16 ` Nick Garnett 1999-12-22 9:56 ` Stuart Hughes 1999-12-22 10:26 ` Nick Garnett 1999-12-23 3:39 ` Stuart Hughes 1999-12-23 4:23 ` Nick Garnett
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).