[snip]
> OK, now we are getting somewhere. So I have a kernel level source, user
> level processing, and a kernel level sink, right? And the problem is that
> we can have long delays which mess that up. Here is how you handle that
> with RTLinux:
>
> There are three processes:
>
> RTLinux producer
> for (;;) {
> sample();
> put_data_in_shared_mem();
> up(producer_sema);
> }
>
>
> Linux processor
>
> for ( ;; ) {
> down(producer_sema);
> get_data_from_shared_mem();
> process();
> put_processed_data_in_shared_mem();
> up(consumer_sema);
> }
>
> RTLinux consumer
> for ( ;; ) {
> down(consumer_sema);
> move_shared_mem_to_device();
> }
>
> I think that 99,000 out of the 100,000 lines of code still lives in the
> Linux process just like it always did. The only difference is that the
> RT processes get scheduled when they need to get scheduled - the Linux
> kernel and all of it's processes get preempted any time a RT process
> wants to run.
Unless I've missed some feature of RTlinux (priotity inversion?) this
still is no good. How often will the userspace process get interupted by
other Linux processes? Will it almost alyways have data ready for the
consumer within 5ms?
If not, then it's still no good.
k
-
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/