> The SPARC port is in its infancy.  How infant?  No code has been written
> yet (though that will change this week).  

Infancy?  That's not even embryotic!  :)

 
> Jordan's statement makes a great deal of sense.  I've traced down
> documentation in preparation for this port that people external to Sun
> would have had a difficult, perhaps impossible time procuring.  Without
> such access, it is very difficult to make continual progress on such a
> project.
> 
> Now it's time to mingle some of my background into this narrative.  I
> started working at SME about 3 months ago.  During my first week I caught
> wind of the negotiations SME was making with FreeBSD core.  I expressed
> extreme interest in working on the project.  Through a bit of persistence
> (and the failure of the proposal made by SME) I was given permission to
> begin work on the port.
> 
> My other duties at SME include finding information for software vendors
> who are porting their OSes/RTOSes to the UltraSPARC.  This puts me in a
> good position to gather hardware information pertinent to the FreeBSD
> port.
> 
> So here's the catch.  I have access to documentation, a machine to develop
> on, but very little low level OS or hardware experience.  I learn quickly,
> but I've got a lot to learn.  Already several people have been able to
> help me grasp concepts that are key to porting FreeBSD, but there is much,
> much more to learn.> 
> So, I can use the following types of help (not exclusively, of course):
> 
> 1) Answer my questions about kernel and hardware details.  For example, I
> have documentation on the MMU, but have never actually dealt with one, so
> John Dyson has volunteered to get me through the rough spots having to do
> with memory management, as well as discussing design issues due to the
> difference in nature between PCs and Suns. 
> 
> 2) Actually write code.  I'll get to some important details about
> this later on in this email.

So what we have here is a Sun employee with access to documentation, but
little low-level experience.  His job is basically to help out vendors
who are in the process of porting to the UltraSparc (like NetBSD? :)

The natural conclusion (to me, at least) is that we (NetBSD users and
developers, if not core) should offer assistance to Jason, in return
for inclusion in the porting process and information pipeline.

NetBSD has a lot to offer, especially the solid multi-platform foundation,
not to mention already existing Sparc ports and drivers (does Jason 
really want to single handedly write drivers for everything?  Porting 
the kernel is just a single step, which is pretty small compared to
turning FreeBSD into an multi-platform OS).

Taking the attitude expressed in the subject of this email is really
counterproductive to NetBSD, and ultimately to Jason and FreeBSD/sparc.



> Q.3.) Why not start from NetBSD/OpenBSD?
> 
> Answered by Jason Evans (jasone@cannonware.com).
> 
> There are multiple answers to this:
> 
> 1) SME specifically wants a FreeBSD port because that's what potential
>    customers have been clamoring for.
> 
> 2) I'm particularly attached to FreeBSD, but don't like supporting Intel
>    (both because of their business practices and because of the quality of
>    their products).

Good question, but unfortunately it goes unanswered...

I wonder if the potential customers know enough about NetBSD to decide what
to clamor over?  And since they probably have a whole lot of non-Ultra
Sparc machines, wouldn't they be interested in a single Free OS that allow
them to create a homogenious environment across all of their Sun systems?



> Q.10.) What's the general plan of attack?
> 
> Answered by Jason Evans (jasone@cannonware.com).
> 
> Briefly, the first challenge is to get the kernel to build using a
> cross-platform development environment.  Next we need a working console
> driver and a completely stripped down kernel to get the kernel to load
> and initialize itself.  There are a number of areas that are going to take
> a lot of work to make even this much happen.  
> 
> There is talk of a source tree restructuring, but my feeling is that we
> should put this off as long as possible, so that when we do it, we have a
> good idea of what we're trying to achieve. 
> 
> The memory subsystem will need to be ripped to shreds and put back
> together.
> 
> There is discussion of how to make bus interfaces abstracted in the kernel.
> 
> Assumptions about the size of int will need fixed.
> 
> There are many, many things to do.  Exactly what order they need to be
> done in isn't completely clear yet, but we'll manage somehow.


Quick!  Someone drop Jason a note about NetBSD before he wasted a lot of
time reinventing the wheel.  There is just no way that adding UltraSparc
support to NetBSD would be anywhere as complicated as totally reworking
FreeBSD into Net^H^H^HFreeBSD/sparc.

I wouldn't want to derail his plans, or otherwise impead FreeBSD/sparc
progress, but it seems like this is a golden oppertunity for NetBSD
to gain from some "inside knowledge" to flesh out the Sparc support. And
at the same time, start to bring NetBSD and FreeBSD closer together, even
if only in this one area.



Jeff Thieleke