From: yodaiken@fsmlabs.com
To: Mark Salisbury <mbs@mc.com>
Cc: yodaiken@fsmlabs.com, george anzinger <george@mvista.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: POSIX 52 53? 54
Date: Fri, 13 Apr 2001 08:59:27 -0600 [thread overview]
Message-ID: <20010413085927.B24060@hq.fsmlabs.com> (raw)
In-Reply-To: <3AD66F56.A827E22@mvista.com> <20010412215323.A17007@hq.fsmlabs.com> <0104130853521R.01893@pc-eng24.mc.com>
In-Reply-To: <0104130853521R.01893@pc-eng24.mc.com>; from mbs@mc.com on Fri, Apr 13, 2001 at 08:46:14AM -0400
On Fri, Apr 13, 2001 at 08:46:14AM -0400, Mark Salisbury wrote:
> these are covered in IEEE P100.13, D9 September 1997 AD212. it is available
> from IEEE for a "nominal" fee.
>
> they are 4 defined subsets of POSIX that are deemed appropriate for real-time
> systems.
>
> unfortunately, the sub in subset is a small delta from the full set.
>
> the subsets are:
> PSE51: Minimal Realtime System Profile
> PSE52: Realtime Controller System Profile
> PSE53: Dedicated Realtime System Profile
> PSE54: Multi-purpose Realtime System Profile.
>
> now, PSE51 is already about 90% of POSIX, so I don't really see what is so
> minimal about it. the others require even more.
Actually PSE51 seems to me to be pretty smart which is why, even though I
swore we would never adopt the bloated, slow, POSIX standard for RTLinux,
the discovery of 1003.13 changed my mind. PSE51 says a minimal RT system
can look like a single process with "main" as the OS and with signal
handlers and threads for applications. They note that POSIX does require
"open/close/read/write", but in PSE51, we don't need to offer POSIX file
semantics: this is actually pretty nice for us. We install interrupt
handlers with sigaction, use the thread/creation deletion and the standard
synchronization API which I have grown to semi-like. 1003.13 gets around
"fork" and such by simply adopting a "single process" semantics. According
to the standard, we gotta have "fork", but it can fail due to too many
processes (Linus hates this, but he thinks CC-NUMA scales, so ...)
Basically, PSE51 allows for a real standard API without requiring the system
to stop being hard realtime.
And then we have one thread as PS54 system so we can do
pthread_kill(linux_thread(), LINUX_IRQ +n)
to send interrupt "n" to Linux
And Alan Cox invented a brilliant method for fault tolerance where the PSE51
system runs a watchdog thread for the OS and has a recovery thread that
does
vulture:
/* wait for death*/
pthread_join(linux_thread())
/* note that critical RT processing continues */
generate_blue_screen("NT EMULATION MODE ON: PLEASE BE PATIENT WHILE
WE RECOVER. .\n");
pthread_create(linux_thread(),&linux_attr,restart_linux,0);
goto vulture;
This could be implemented quite easily.
>
> On Thu, 12 Apr 2001, yodaiken@fsmlabs.com wrote:
> > POSIX 1003.13 defines profiles 51-4 where 51 is a single POSIX
> > process with multiple threads (RTLinux) and 54 is a full POSIX OS
> > with the RT extensions (Linux).
> >
> > On Thu, Apr 12, 2001 at 08:15:34PM -0700, george anzinger wrote:
> > > Any one know any thing about a POSIX draft 52 or 53 or 54. I think they
> > > are suppose to have something to do with real time.
> > >
> > > Where can they be found? What do they imply for the kernel?
> > >
> > > George
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
> > --
> > ---------------------------------------------------------
> > Victor Yodaiken
> > Finite State Machine Labs: The RTLinux Company.
> > www.fsmlabs.com www.rtlinux.com
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> /*------------------------------------------------**
> ** Mark Salisbury | Mercury Computer Systems **
> ** mbs@mc.com | System OS - Kernel Team **
> **------------------------------------------------**
> ** I will be riding in the Multiple Sclerosis **
> ** Great Mass Getaway, a 150 mile bike ride from **
> ** Boston to Provincetown. Last year I raised **
> ** over $1200. This year I would like to beat **
> ** that. If you would like to contribute, **
> ** please contact me. **
> **------------------------------------------------*/
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
prev parent reply other threads:[~2001-04-13 14:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-13 3:15 george anzinger
2001-04-13 3:53 ` yodaiken
2001-04-13 12:46 ` Mark Salisbury
2001-04-13 14:59 ` yodaiken [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010413085927.B24060@hq.fsmlabs.com \
--to=yodaiken@fsmlabs.com \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbs@mc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®