From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stuart Hughes To: Nick Garnett Cc: elix@sourceware.cygnus.com Subject: Re: RTLinux workshop and EL/IX press coverage on EETimes Date: Thu, 23 Dec 1999 03:39:00 -0000 Message-id: <3861F6B9.1FA6C63A@zentropix.com> References: <01d801bf4c95$b7938640$2f2782c2@cygnus.co.uk> <38611114.8CE7C1D@zentropix.com> X-SW-Source: 1999-q4/msg00015.html Nick Garnett wrote: > > Stuart Hughes 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.