public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] I-pipe: Introduction
Date: Sat, 18 Jun 2005 01:21:28 +0200	[thread overview]
Message-ID: <42B35AF8.9060301@xenomai.org> (raw)


For the past five years now, I've been working on various real-time
solutions for Linux. Part of this involvement has been the development
of what has been known for a while as the Adeos nanokernel, and also
the refactoring of RTAI and its reimplementation known as the "Fusion"
track within this project. In order to take this work to the next step
and further increase the collaboration and integration with mainstream
kernel development, the following patchset introduces the
interrupt pipeline for Linux.

The I-pipe (in its abbreviated form) is a much stripped down version of
the interrupt pipeline that was contained in the Adeos implementation.
This refactored patchset retains many of the same properties of its
Adeos ancestor, including the ability to implement an executive running
side-by-side with Linux, albeit with less integration with Linux as was
possible with the full Adeos.

Most importantly, this patch makes it possible to obtain deterministic
interrupt response times from the Linux kernel without any further
additions or modifications. A driver, for example, may register a
handler as part of a priority interrupt domain in front of Linux and
thereafter obtain its interrupts in a deterministic fashion regardless
of whether any piece of Linux code has disabled interrupts. Also, it
should be relatively simple to create future iterations which would
allow what remains of Adeos to load itself on top of the I-pipe in
order to allow multiple executives to run side-by-side with Linux in a
fully-integrated fashion, as in Fusion for example.

Basically, the I-pipe inserts itself between the interrupt-management
hardware and Linux. Any attempt from any Linux component to disable
interrupts results in Linux's I-pipe stage to be stalled. While stalled,
a pipeline stage will not receive interrupts. However, any pipeline
stage of higher priority will continue receiving interrupts, unless it
too stalled its own stage. It follows that interrupts are almost never
disabled.

I've broken down the patch into a core set of changes and an x86
architecture-dependent implementation. As you will notice, the changes
in both cases are mainly the addition of the files implementing the
I-pipe, specifically:
- include/linux/ipipe.h
- include/asm-i386/ipipe.h
- ipipe/*
- kernel/ipipe.c
- arch/i386/kernel/ipipe.c

Note that this patch can be conjugated with PREEMPT_RT, as had been
previously demonstrated by the availability of a combo patch including
both Adeos and PREEMPT_RT. I therefore encourage those interested in
PREEMPT_RT to review the I-pipe patches.

Looking forward to your feedback,

-- 

Philippe.



                 reply	other threads:[~2005-06-17 23:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=42B35AF8.9060301@xenomai.org \
    --to=rpm@xenomai.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox