That would be nice. But what is the technical content?
> 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.
> 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.
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.
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.
/* plan-9 interface to RTLinux sched! Not implemented. */
fd = open("/dev/rtsched_command",2);
fd2 = open("/dev/rtsched_data",2);
write(fd2,&task,sizeof task);
write(fd,"run task at a 100us period please",n);
> The soft realtime part should definitly be done in user space. Things get
> better here, but here is still a lot to do...
I'm not sure about this either.
-
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/