Re: a joint letter on low latency and Linux

[Larry McVoy]

> > If that's not right then please tell me how it works.  If that is more or
> > less right, then it seems to me to be trivial to open up a pipe to a real
> > time process which does the sampling and away you go.  
> 
> it's more then just sampling and storing the data. they are currently
> using the approach that you describe (drivers do the IO, processing in
> user space. the trouble is that the user space processing can be delayed
> to the point that you get a buffer underrun so if you use RTLinux to fix
> this then your userspace code needs to be converted to RTLinux code. Thus
> the "thousands of lines of code" that need to be converted.

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.

Think about this.  You already have a mechanism that gives you exactly
what you need.  And it is _way_ better than any of the proposed hacks.
The only complaint that is valid is that it is "different".  Yup, that's
true, the wheel was different too.  Such is life.  You have to give a 
little to get a lot, that's a better tradeoff than you normally get.