Comments on: Emerging Technologies: Developments in Red Hat Enterprise Linux RealTime http://www.press.redhat.com/2007/06/05/emerging-technologies-developments-in-red-hat-enterprise-linux-realtime/ Red Hat News, straight from the source. Fri, 29 Aug 2008 07:46:31 +0000 http://lyceum.ibiblio.org/?v=1.0.2 by: Eric Schafer http://www.press.redhat.com/2007/06/05/emerging-technologies-developments-in-red-hat-enterprise-linux-realtime/#comment-4 Mon, 02 Jul 2007 19:27:26 +0000 http://www.press.redhat.com/2007/06/05/emerging-technologies-developments-in-red-hat-enterprise-linux-realtime/#comment-4 Why invent another message queue mechanism when you are standardizing on Native Posix Threads (NPT) and POSIXs in general. Why not create a clean object interface to POSIX IPC and synchronization calls (POSIX has a message queue capability. Since that is the O/S native message queue it will be faster than any middleware implementation.). Reducing non-preemption intervals is a great 1st step Montivista spearheaded in the open 2.6 kernel with improved device driver design. Is the scheduler and NPT portion of the system call library being advanced to avoid resource related thread and/or process lock ups (Requires priority inversion Mutex implementation. Inter-process support might suggest augmented use of name space parameter already employed by other POSIX IPC calls.)? Has any collaboration with Intel been sought because multiple CPU chips may require hardware acceleration of inversion lock within kernel logic? At a minimum, this fix will require collaboration between Ingo and Ulrich. Finally, it might be nice to modularize the name space mechanism within the system call library, so inter-process support can be added to POSIX process, POSIX thread, and POSIX IPC calls. Why invent another message queue mechanism when you are standardizing on Native Posix Threads (NPT) and POSIXs in general. Why not create a clean object interface to POSIX IPC and synchronization calls (POSIX has a message queue capability. Since that is the O/S native message queue it will be faster than any middleware implementation.).

Reducing non-preemption intervals is a great 1st step Montivista spearheaded in the open 2.6 kernel with improved device driver design.

Is the scheduler and NPT portion of the system call library being advanced to avoid resource related thread and/or process lock ups (Requires priority inversion Mutex implementation. Inter-process support might suggest augmented use of name space parameter already employed by other POSIX IPC calls.)? Has any collaboration with Intel been sought because multiple CPU chips may require hardware acceleration of inversion lock within kernel logic?

At a minimum, this fix will require collaboration between Ingo and Ulrich. Finally, it might be nice to modularize the name space mechanism within the system call library, so inter-process support can be added to POSIX process, POSIX thread, and POSIX IPC calls.

]]> by: Matthew Renodin http://www.press.redhat.com/2007/06/05/emerging-technologies-developments-in-red-hat-enterprise-linux-realtime/#comment-3 Mon, 02 Jul 2007 14:01:17 +0000 http://www.press.redhat.com/2007/06/05/emerging-technologies-developments-in-red-hat-enterprise-linux-realtime/#comment-3 I am researching real time linux to replace old OS9. So far my trouble has been in hardware. I am working on developing drivers to meet our needs and porting software from OS9 to FC6 w/ the rt kernel. I feel there are several things that will be needed and maybe it will be a red hat service. That is a scheduler that is easy to interact with and an API (the worst part of a project). I have requirements that need determinism and need to be in (us). I am open to beta testing. I am researching real time linux to replace old OS9. So far my trouble has been in hardware. I am working on developing drivers to meet our needs and porting software from OS9 to FC6 w/ the rt kernel.

I feel there are several things that will be needed and maybe it will be a red hat service. That is a scheduler that is easy to interact with and an API (the worst part of a project).

I have requirements that need determinism and need to be in (us).

I am open to beta testing.

]]>