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 POSIX 52 53? 54 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.