When we build pSOS,  we have separate kernel and user trees.  We have a driver,  AppSysDrvr,  which can be called by the user side to return kernel-related  information,  including the location of specific root pointer to kernel strucures,  etc.

It maintains a nice indepencence between the two without significant handicaps for those user programs that must "know" things about the O/S.

Perhaps there is some similarity here.

Regards,

Mike Cravens

Senior ( Real Time) S/W Egr.

Alcatel USA
 

Kirk Smith wrote:

> From:          [EMAIL PROTECTED]
> Date:          Fri, 12 Mar 1999 09:01:05 -0700
> To:            Jochen Kuepper <[EMAIL PROTECTED]>,
>                Real-Time Linux <[EMAIL PROTECTED]>
> Subject:       Re: [rtl] Real Time Application Interfaces/

> I want to keep a separation. RTL programmers don't need to be kernel hackers and vice-versa.
> That is, if you want to learn how to write RTL tasks and handlers, you should not necessarily
> need to learn the Linux kernel os tree. Furthermore, it's not good modularity to put rtl headers, only
> referenced by rtl modules, in the linux kernel tree. Ideally, one should be able to pop a new patched  linux kernel
> into rtlinux/linux or a new rtl distribution into rtlinux/rtl without worrying about the other side.

This is a VERY important design choice for me.  In fact, I am evaluating
RTLinux as we speak, and one of the key features that makes it stand out over
Embedded NT (which several CS people here are pushing) is that the RT apps are
on the complexity level of DOS applications,  Where Embedded NT requieres
Device Driver (an art in itself) experiece to do even the most basic of tasks.
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/

-- 
   Alcatel USA              Internet: [EMAIL PROTECTED]
  1000 Coit Road Plano, Texas 75075
  **** The opinions expressed are not those of DSC Communications, Inc ****
 

Reply via email to