All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karim Yaghmour <karim@domain.hid>
To: Timothy_J_Massey/TheModernMerchant@domain.hid
Cc: Philippe Gerum <rpm@xenomai.org>, adeos-main@gna.org
Subject: Re: Realtime on top of Adeos (Was: Re: [Adeos-main] [ANNOUNCE] Adeos M2)
Date: Wed, 17 Jul 2002 21:44:41 -0400	[thread overview]
Message-ID: <3D361D89.EE39DC2B@opersys.com> (raw)
In-Reply-To: OFF782B728.BFF318FC-ON85256BF9.00772E1C-85256BF9.007B8E4C@LocalDomain

Timothy_J_Massey/TheModernMerchant@domain.hid wrote:
> Quick question:  how does Adeos affect real-time response?  Wouldn't Adeos have to be real-time itself, and wouldn't the (guaranteed) latency of
> Adeos be added to the latency of the upper level RTOS?

Adeos doesn't know anything about real-time. All it sees are hardware
resources that client OSes need to share. Currently, Adeos allows the
most basic resource required to run OSes, interrupts, to be shared.
As is done in many nanokernels before it (see Exokernel paper), Adeos
provides for an orderly delivery of hardware resources.

If an RTOS is indeed running on top of Adeos, then it certainly does
have to contend with the fact that Adeos' code will always run before
the RTOS' interrupt handler. This code delivers the interrupts in the
order of domains found in the interrupt pipeline, which is pretty
much up to the system designer. If Linux is first, then it gets it
first. If a kernel debugger is first, then it gets it first. If an
RTOS is first, then it gets if first.

If we are talking about real-time on conceptual grounds, however, note
that "real-time" is not so much an issue of speed as it is an issue of
guaranteed deterministic behavior.

I had some interesting discussions at the OLS with Daniel Phillips about
Adeos. He was pointing out that one interesting application for Adeos
was to run 2 RTOSes side-by-side, each responsible for tasks running at
a different resolution. For example, the first RTOS in the pipeline
would be responsible for tasks that need microsecond resolution, while
the second RTOS in the pipeline would be responsible for tasks that
need millisecond resolution.

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================


      reply	other threads:[~2002-07-18  1:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-17 21:44 Realtime on top of Adeos (Was: Re: [Adeos-main] [ANNOUNCE] Adeos M2) Timothy_J_Massey/TheModernMerchant
2002-07-18  1:44 ` Karim Yaghmour [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=3D361D89.EE39DC2B@opersys.com \
    --to=karim@domain.hid \
    --cc=Timothy_J_Massey/TheModernMerchant@domain.hid \
    --cc=adeos-main@gna.org \
    --cc=rpm@xenomai.org \
    /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.