Herman Bruyninckx wrote:
>
[ Asymetric Multiprocessing with Linux and another RTOS ]
> Sounds great, for things such as machine control, where you need a known
> and invarying number of small tasks that just have to run very fast.
Thatīs not the point! RT-Linux (and RTAI as well) are just fine
for this purpose - except the latencies caused by potential
cache misses are to big (usualy < 5 ĩs - IMHO, thatīs quite ok
for advanced machine control, but who knows?). On the
other hand, you could virtualy any other open-source OS run
in parallel with linux. People with huge experience with
the other operating systems could move to an linux-enhanced
environment without changing their mind ... it would
even enable other makers of operating systems to
modifiy their os so that it can run in parallel.
The only point is resource management: you have
to tell the other os explicitly which PCI-cards
and memory areas it can use ... (imagine BEOS with
itīs own GFX-card running in parallel with linux).
> > If there are enough people out there, interessted in that idea, we could
> > revival the project.
> I'm interested! I guess the same thing would work with ecos too?
> (<http://www.redhat.com/products/ecos/>)
Very likly ... you just have to bootstrap the second
processor and tell the upcoming os which recources it
is allowed to use ...
The first step is already somewhat done ... but right
now, itīs an awfull hack ... we (three engineerers)
only spend 8 hour on the problem a year ago :-)
I will have a look for the kernel-diffs we produced:
actually i canīt find them on my local disk drive - i
very likely have to ask my former colleagues
for the patches ... but i suggest to withdraw
the code, begining from scratch, anyway
The old code realy was a hack:
The SMP-Kernel is coming up as usual. Then
the second processor jumps to the desired
code via a dedicated "trampoline", and
the it is disabled in the
linux processor list just befor the
kernel enters the scheduler (thus
all linux-tasks will have to start on the
first processor)
The better solutions would be:
The kernel comes up in UP mode or
with the kerneloptions "numcpus=1" and "mem=<MEM-x>m".
Later, a kernel module could wake up the still
sleeping second processor: just have a look at smp.c,
the wakeup-code could be copied easily.
The module has a mandatory parameter like "start=0x7F00000"
(if you have reserved the top 1 Mbyte for the other
os on a machine with 128 Mbyte of memory)
Of course, you first had to copy the code of the
second os to this location in some way, maybe with
another kernel module using the /proc-fs)
In this way, you even wonīt have to modify the kernel,
and the system would just work with any Distribution ...
But there also could be a gerneric
interface in the kernel to wake up the second
processor, using the /proc-filesystem, for
example:
echo 0x7F00000 > /proc/amp/cpu1/start
In this way, you donīt have to copy
the wake-up code from smp.c, but i am not
sure, if this is the simpler way to do ...
(iīd like to prefer the first way)
BTW: The two operating system could easly talk to
each other, using shared memory and the APICs
(simulated interrupts, etc.)
just an idea ...
comments?
Bernhard
-- [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/
