Re: real-time threaded IO with low latency (audio)

David Olofson (audiality@swipnet.se)
Sun, 25 Jul 1999 21:04:39 +0200

yodaiken@chelm.cs.nmt.edu wrote:
>
> On Sun, Jul 25, 1999 at 08:20:06PM +0200, David Olofson wrote:
> > > 3. any other trap or error condition that puts us in K mode.
> >
> > Does this need to be handled without losing the RT timing, or is it
> > "just" a matter of handling it to keep RT an error condition from
> > causing a bad crash?
>
> Linux may die horribly if it allows the RT task to enter kernel mode.
> So we would have to put guards on all kernel entry points
> if running rt process (note current will not be useful)
> then
> call rt scheduler with error indication
>
> the rt scheduler would then mark the current rt task with an error
> condition and let it handle it. We'd bypass the linux scheduler entirely
> and would have to add a RT call
> run_user_mode_process(p);

Ouch. Not exactly a little nice hack...

> Doesn't sound so bad now. A error would basically loose RT functionality: that seems
> ok. But it would require a bigger Linux patch.
>
> I described this idea to Linus and it made him deeply unhappy.

I'm not surprized! It would be cool for RT hackers, but it isn't exactly
beautiful...

To me it sound like the problem should be solved on some other level.
Problem is; where? Where's the narrowest place to do the cut? What I see
is sync problems between RT "kernel" mode and real kernel mode. Making
the sync primitives RT aware/safe? Am I missing some important problem
here? (I haven't studied the application->kernel mode switch yet...)

//David

-
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/