[EMAIL PROTECTED] writes:
> On Thu, Jun 29, 2000 at 11:25:27PM -0400, Paul Barton-Davis wrote:
> > No good.
> >
> > This assumes it takes zero time for the linux process to do its
> > thing. If you were running a faster clock, and could tell "ahead of
> > time" that the linux process hadn't run yet, you could recover. but
> > otherwise, the RTLinux process is going to run because an audio
> > interface interrupted, and by that time, it will be too late to try to
> > generate the data that should have been computed already. Recall: the
> > RTLinux consumer's job is to move data from shared mem down to the
> > audio interface. If the data is not ready when it runs, its already
> > too late.
>
> I'm adding a feature to our RTLinux consumer. It collects a frame
> and dumps it, then it looks at the queue -- if the queue is at a low
> water mark, the RT consumer reaches down into Linux, sets
> need_resched and boosts the priority of the Linux process, if Linux
> is in user mode it might even be worthwhile to generate a timer
> interrupt for Linux. This "runs a faster clock" and can look ahead.
Urg. This is ugly. It's also dangerous, because it fouls up time
accounting. You'd effectively be changing HZ without telling everyone
to update their current HZ value to compensate.
> I want to try this trick on TCP/IP sometime.
I think having RTLinux going in and grope the kernel all over is just
asking for trouble. That path leads to madness. It will add a tight
dependency between the internals of Linux and RTLinux. Take it from
someone who knows: tracking kernel drift is a bitch.
Again: this is why I like my idea of scheduling user-space RT
processes with the RTLinux run queue. Only a few well-defined places
are needed for Linux/RTLinux to co-operate.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
