On Fri, Dec 22, 2000 at 01:39:02PM +0100, Ignatios Souvatzis wrote:
> > so the way I see this turning into a directory structure is:
> > 
> > sys
> > 	arch
> > 		m68k
> > 			m68k
> > 			amiga
> 
> Pleasenot. You're aware that we're preparing an amigappc port?
> Same devices (with the exception of system clock, of course) as Amiga86k,
> but different bootloader and different userland and different pmap?

I didn't mean to imply that there's shouldn't be a port for powerpc-based
amigas, just "amiga" has always been the NetBSD name for the m68k-based amigas.
perhaps you'd like to change that to "amiga68k" to make the distinction?
"amiga68k" would be supported by the m68k port and "amigappc" would supported
by the "powerpc" port.

as for code shared just between amiga68k and amigappc, I was thinking exactly
what Ben said, put that in a "dev/amiga" directory.


> (There's also NewsMIPS vs. News68k, but I don't know how similar those are.)

same as above, make a "dev/news" if there is hardware that is specific to
the two "news" platforms.


> I think it is more useful to do:
> 
> sys
> 	cpu
> 		m68k
> 		powerpc
> 		arm
> 			common
> 			arm32
> 			arm26
> 	arch
> 		amiga(68k)
> 		amigappc
> 		

how is this more useful than what I proposed?  the intent with my idea
is to encourage the production of single kernel images with can run on
different hardware with the same cpu that are currently considered
separate "ports", such as sun3x vs. hp300.  in your proposal, how would
this work?  some kernels built under "arch/foo" and others under "cpu/bar"?
in my proposal, all the m68k kernels would be build under "arch/m68k",
there would just be separate kernel config files for each set of hardware
that could not yet use the unified m68k kernel.

could you give some details on the advantages of your proposal?


> And maybe provide build tools that allow to create installation media more
> easily.

absolutely.  we should be building installation tools that are targeted
to different installtion mechanisms (ie. "floppy", "tape", "cdrom")
rather than different "ports".  I think we already do this to a large
extent.  the installation process needs to know about the differences
between eg. sun3x and hp300 only in as much as they have different boot
mechanisms, which includes disklabel and bootblock issues.


> It might or might not be useful to split machines accross port maintainers.
> It surely is of little use to have a split-off port with nobody to actively
> maintain it.

no source tree layout will make up for the lack of anyone working to support
a given class of hardware.  more unification in hardware support means that
people may have to work together more than they currently do, but I would
think that would be a good thing anyway.

-Chuck