At 07:34 AM 8/13/2002, Jochen Kunz wrote:
>On Sun, Aug 11, 2002 at 12:22:05PM -0700, Matt Thomas wrote:
>
> > My inclination is to have to move to a rs6k port and have
> > GENERIC and GENERIC64 for 32bit and 64bit PPC platforms.
>This would require a 32 bit userland, as 64 bit applications can't
>run on a 32 bit machine and 32 bit applications will run in some
>kind of emulation when a 64 bit kernel is running?

Yes it would.  But one advantage to this is that 32-bit programs
are usually smaller and use less memory than their 64-bit counterparts.
Note that more Solaris/SPARC program are 32bits even though the
kernel is 64bits (for UltraSPARC).

>(Sorry for this questions. I don't have The Clue (C) (R) (TM), but
>I wane learn more about all this OS internas. This is the reason
>for my interrest in getting the rs6k port going: Learning by doing.)
>
> > The real question is do we want a single kernel which can work
> > on 32bit and 64bit platforms?
>Stupid question: How can this work? A single Kernel for 32 and 64 bit
>machines? Wouldn't the 32 bit compatibility force compromises that we
>probably don't want? Like a 4GB address space limit?

All 64-bit PPC CPUs can run 32-bit PPC code since it the same
instructions (you just aren't executing any 64 bit instructions).
The real issue is that the 32bit kernel needs to deal >32bit physical
addresses.  But some 32bit PPC CPUs (Motorola MPC745x and IBM 405GP)
already can deal with 36bit physical addresses so when/if we ever
support those physical address models, we will need 64bit physical
address support even in 32bit kernels.

> > The most significant thing is to create a RTAS module with the
> > various functions we need.
>As I understand the CHRP spec and the CHRP to OFW binding RTAS is a
>CHRP speciffic extension to OFW, so there is no RTAS already in NetBSD
>(macppc e.g)?

Correct, no RTAS in macppc.  Though, just like PReP, we can write
a RTAS work alike which has the intimate knowledge of macppc machines.

The advantage of this is that we start supporting more machines out
of a single "port".  chrp, prep, ofppc, macppc could all be combined
into one port (for example).

> > Now if we do it right, there could
> > be an RTAS work-alike implemented for PReP.
>I had a brief look into the PReP spec. There is also some hardware
>abstraction called RTAS. But the PReP RTAS is hardware _and_ OS
>dependend. The PReP spec "defines the functions that must be abstracted,
>but it does not define the interface to the operating system nor does
>it define the way the functions are collected into usable services."
>[...] "Initial versions of the RTAS are distributed by an operating
>system vendor." I.e. we have to write our own PReP RTAS. We are free
>to choose an OS interface for it so (perhaps) we can make it CHRP
>compatible.

That would make the most sense.

> > But the most significant difference is that one uses a PC'ish
> > PNP database and CHRP uses OFW.
>Next stupid question: Can't this be solved by attaching different busses?

It could and will.  but the point to use the device configuration
information that the firmware gives us, not to do self-discovery
(unless we really really have to).

-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message