>>>>> "yodaiken" == yodaiken <[EMAIL PROTECTED]> writes:
yodaiken> On Mon, Feb 14, 2000 at 05:00:22PM -0500, Paul Koning
yodaiken> wrote:
>> I noticed that (at least in 3.0) there's a config symbol for
>> RTLinux. But it isn't being used in the usual way -- the RTL code
>> dropped in by the patches isn't controlled by #ifdef
>> CONFIG_RTLINUX (with one or two exceptions) -- and it isn't a
>> configuration dialog question.
yodaiken> CONFIG_RTLINUX is useful to export that it is a RT
yodaiken> kernel. But once the patch is installed, there is no point
yodaiken> in pretending it's not a RTLinux kernel so a config option
yodaiken> is useless.
Certainly it's nice to know it's an RTLinux kernel, but I don't
understand the other point. RTLinux to me is a kernel "feature" just
like, say, IPSEC support or SCSI tape support.
>> Are you planning to do that? It would seem to make sense that way
>> -- for example, presumably that's what would be needed before RTL
>> could become a standard part of the kernel, rather than an
>> ever-evolving but never-merging patch. Having it integrate into
>> the standard kernel would be a major win.
yodaiken> RTlinux _is_ integrated into the standard kernel in the
yodaiken> sense that the irq code has been reritten to make the
yodaiken> RTLinux patch easier to maintain and simpler. I
yodaiken> reorganized irq.c for this reason -- although Linus took
yodaiken> the patch partly to facilitate a more arch independent
yodaiken> style of irq handling.
yodaiken> Linus is very reluctant to give up the 8bit cli's/sti's in
yodaiken> x86 vanilla Linux, and I believe he is also quite happy to
yodaiken> not have to deal with the RT issues when he already has a
yodaiken> few other things to worry about. So x86 Linux will still
yodaiken> require either getting a RTLinux version or running the
yodaiken> patch. Note that PPC, however, does not have this
yodaiken> requirement since PPC already needs some indirection that
yodaiken> we use to grab interrupts.
I certainly wasn't suggesting giving up the 8bit CLIs etc. That's the
whole point! A CONFIG_mumble feature that drives assorted #ifdef's
lets you turn something on and off. Every other feature of the Linux
kernel, as far as I can tell, works that way. RTLinux is the only one
I've heard of that comes in the form of a patch AND plans to keep it
that way. Compare with, say, DECnet, which started out as an enormous
patch, but is now simply another networking config options. IPSEC
isn't there yet, but the reasons for that have to do with (now
hopefully obsolete) US regulations, not any Linux considerations.
It's clear that one could rewrite the patch file to make RTLinux a
configurable option, such that having it undefined gives you a Linux
kernel exactly as today, and having it defined gives you an RTLinux
kernel again exactly as today. If you had that, then the entire
contents of kernel_patch could move into the standard Linux
distribution. For one thing, that would make it a lot easier to track
different kernel versions...
paul
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
