Paul Barton-Davis writes:
> >In fact, probably the best option is to write (or sponsor) a patch to
> >RTLinux so that Linux user-space processes can be scheduled by the
> >RTLinux scheduler.
>
> In other words, you want all the junk to be in RTLinux :)
No, because it wouldn't be a pile of random patches. It would be a
patch that adds a hook between Linux and RTLinux in a small number of
well-defined places. It would be conceptually clean.
It may even be possible to isolate the change to the Linux scheduler.
So that's just one place we'd need to change.
> I think we've explained several times why RTLinux is not an
> attractive option, even if some of us accept that may be a necessary
> step. Do you want to run binary-only RTLinux executables ?
IIRC, you don't like RTLinux because you don't like the programming
model. And if you search back a couple of years, you'll see I've
complained about the RTLinux API as well. Not that it's ugly, just
that it's different.
But my suggestion doesn't require you to convert all your SCHED_FIFO
user-space code to the RTLinux API. You get to keep using the Unix
API. So what's the problem?
And why should I care about binary-only RTLinux executables? At least,
any more than binary-only Linux drivers, or binary-only suid-root
executables?
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:12 EST