[openbeos] OBOS R1 PPC Compatibility
- From: Teh Kelvin-CKT044 <Kelvin.Teh@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 12 Jan 2002 16:26:33 +0800
Hello all,
I have been following this list for quite a while, but rarely posted anything
so far.
However, I just thought I would just chip in with what I think about the recent
PowerPC-related exchanges between Nathan Whitehorn and Michael Phipps.
I realize that it might be a little bit hard to include full PowerPC support in
OBOS R1.
However, as had been pointed out previously, there are other parts besides the
kernel and low-level driver codes involved in OBOS.
I think it would be a good idea to require that all codes written for
non-kernel, non-driver codes (e.g. Media Kit, Game Kit, Networking, etc.) to be
written in such a way that the modules will work without modifications when
compiled and plugged into BeOS 5 PPC.
From what I understand, these kits should be able to be plugged directly into
BeOS 5 to replace the corresponding components in BeOS 5.
They are also supposed to be hardware platform independent anyway, if good
software design approaches are followed.
If the codes doesn't work in BeOS 5 PPC, then the code is probably badly
designed and should be revised.
Besides, this would be keeping to the official OBOS R1 goals of recreating an
OS as close as possible to BeOS 5 (I would imagine, for instance, that the
codes for the Media Kit shouldn't differ significantly between BeOS 5 Intel and
BeOS 5 PPC, although, of course, I do not know).
As such, I would suggest that all non-kernel, non-driver OBOS codes be tested
on BeOS 5 PPC besides BeOS 5 Intel and found to be working before it is allowed
to be merged in, unless it can be shown that this is unavoidable, perhaps
because of the usage of assembly language (which should be kept to a minimum
anyway for good design, as pointed out by Michael Phipps), or because some
Intel-specific codes had to be used in order to reduce coding time (by right,
shouldn't occur when writing good, platform-independent software design, but it
is understood that OBOS is facing a lack of programmers, so this might be
needed).
In any case, these exceptions should be clearly documented in order to ease the
addition of the corresponding PPC codes later.
I believe that these tests shouldn't take too long to do for each merge (if the
code is written well, probably less than ten minutes to test on a BeOS 5 PPC).
Although the amount of additional time spent at this stage to keep the codes
compatible on BeOS 5 PPC is minimal, it will potentially save a HUGE amount of
time when trying to create a PPC version of OBOS later in R2.
Anyway, that's just my $0.01 worth..... feel free to think about it or
disregard it if it is not a good idea at this stage.
Best regards,
Kelvin
Other related posts:
