"atomic macros" + "more flexible" + "zero interrupt latency" +
"scale better" etc -- these are terms that do not express any
technical information, but rather express an emotional state of
hopefulness and confidence which is admirable but leaves the reader
just as ignorant as before.
> > > 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.
Look at global_cli and think again.
If what you mean by "atomic macros" is a set of lock-free and/or
atomic operations on data structures, that's a laudable project and
one that needs to be done. But it does not solve the synchronization
problem anywhere near enough to make ordinary synchronization
RT friendly.
The optimization goals of rt and non-rt synchronization code are totally at
odds with each other. For example, the Linus/Ingo design of x86
semaphore locks is to-the-bone efficient for non-RT, but is
terrible for RT since worst case behavior is poor. Ted's bottom halves
solve several synchronization problems for Linux kernel, at the
expense of introducing latency. And etc.
>
> > > 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.
Realtime programming is for people who know what they are doing.
And the experiences of users has been generally really positive.
And feel free to invent your own standard -- everyone else does.
BTW, it may be worth pointing out that RTLinux is in actual production
use in many many sites from NASA to Tokyo University and that, as with
Linux, it seems to be the case that the users are a lot smarter than
many suppose.
>
> > 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.
Good luck. But, you missed my point.
>
> > 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.
Hard RT in user space is not something I know how to do yet. I look forward
to seeing your code.
-
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/