On Fri, 12 Nov 1999 yodaiken@chelm.cs.nmt.edu wrote:
> > I have a set of atomic macros like in asm/atomic.h, but these are more
> > flexible. I'm currently designing a rt scheduler basing on them, that
> > will have zero interrupt latency and does even scale better, but due to
> > lack of time, it's far from ready yet.
> > Anyway, with these macros it would be possible to improve both the normal
> > code and interrupt latency.
>
> That would be nice. But what is the technical content?
What do you mean?
> > Complex rt systems use a multilevel approach anyway and only the hard rt
> > part should be in the kernel, but IMO it should look like a normal driver.
>
> It's hard to see how such an approach can work unless your meaning is
> that we should put the scheduler in a module -- in which case, this is
> what we do. The key problems are that RT interrupts are not like
> ordinary interrupts and RT synchronization _must_ be decoupled from
> ordinary synchronization.
Except ordinary synchronization is realtime friendly, what I try to
achieve with the atomic macros.
> > I'm not really comfortable with the idea putting a pthread interface at
> > kernel level, it suggest that everything works like in userspace, what
> > isn't true.
>
> That's the POSIX standard. And the standard explicitly allows for the
> hard RT part to _not_ behave like ordinary userspace. The alternatives
> are (1) use a nonstandard API that is obviously not userspace and
> (2) use a standard API that has a specified and well known meaning in
> two different spaces.
The standard is one thing, the reality is another. You should have read
enough mails on the RTLinux mailing list from people who have almost zero
kernel programming experience (e.g. because it's some university project)
and I expect a support nightmare, if they try to do the same what they
know from user space programming.
> In any case, you now shifted from an argument about low level irq
> handling to one about the scheduler API and it is a big mistake to mix the two.
The problem is that I prefer a different design, that is better integrated
into the standard kernel.
> RTLinux scheduler is a drop-in module. You can write a scheduler that looks
> like a Linux driver if you want,you can write a scheduler that takes Perl
> strings as input if you want, you can write a scheduler that looks like
> QNX or VxWorks or Window-CE.
But the problem with them is you can only create kernel level rt tasks, it
doesn't get you anything in user space.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/