Development Plan Proposal for Unifying Interrupt and PCI APIs

[Bogdan Vacaliuc]

Hi Eric,

On Monday, October 25, 2004 1:02 PM, Eric Valette wrote:
> OK. I see no point to this kind of virtualization that has been
> designed to make several OS coexist on the same hardware (e.g ADEOS,
> RTLinux, ...) without really modifying the OS originnal code. It hads

But I wasn't talking about making different OS coexist; I was talking about the conceptual implementation for *an* OS which has
support for multiple chips and platforms.  You have to concede that the problems faced (and solved by) making different OS coexist
is similar to the one we are discussing.

> overhead and slowdown without actually solving our initial problem
> that is defining an API is a kind of virtualization by its own.

Overhead and slowdown depend on the implementation.  I tried to keep things at the conceptual level to avoid this exact response
from you.  Unfortunately, as soon as an example is given, it invites just this sort of judgment.

Lets put away the notion of implementation for a moment and think about the problem in an abstract way.  Then, when we are all
comfortable with the model, I am willing to bet that the good people of RTEMS will find a clever way to address the performance
issue that will arise.

---

The basic problem that virtualization (of priorities) solves is the one where a chain of shared interrupt handlers delays the
service of higher priority interrupt handlers as defined by the OS/BSP/application/whatever.

The basic problem that shared interrupts solves are the physical limits of the specific hardware.

We have identified a case in which a hyperactive device on a shared interrupt line starves or delays less active devices on the same
line.  Dealing with this case by design is what we are trying to accomplish, and virtualization of all interrupts is one proposal.

Another proposal I had made in my note is to manage shared interrupts differently than non-shared interrupts.


-bogdan