In preperation for starting some substantial work on getting an m68k port
of rtlinux in the works, some definate management issues have occured to
me, so I thought it might be about time to get input from the list on
handling these things, to avoid headaches down the road...
First, obviously, as the main kernel devel sources are forked for m68k,
then any RTlinux port working on m68k is going to have to fork also.
Unfortunate. How has this issue been handled on other ports (alpha, at
least, is rumored to be in the works)?
Also, m68k suffers from the problem that virtually all of the m68k systems
which linux has been ported to have different IRQ controllers in addition
to the normal 68000 interrupt handling. Unfortunate as well, as this
means that the likelyhood of having an m68k port with integration anytime
in the forseeable future is virtually nil.
Next, I was wondering if the RTlinux project as a whole had any plans
on changing the framework to allow easier cross-arch development...
thinking here of perhaps having seperate patches for the common and
arch-specific hunks of code. Though, as no non-i386 port seems to be
close to ready for prime time, this might be a little far off.
Finally, at least in the 68000 case, there's no SMP at all. Any reason to
keep the levels of abstraction used for multi-processor splits? Or would
it be valid to glom back into a single-processor only setup for the
arch-specific code? (and does the non i386/* code assume SMP capabilities
always?)
I'm sure there are more and larger considerations... I'll cross those
bridges once i've finished the needed rewrites...
-- Sam
"UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT
Information is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS."
-- Robert E. McElwaine
--- [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/
