I'm with Ig on this issue, I think we should fix the problems with merged
ports rather than give up on that idea and split up the merged ports.

one of the guiding princples that we're all supposed to be following when
working on NetBSD is that we should make code as common as possible.
it seems to me that any two pieces of hardware that can run the same
userland binaries should be in the same "port".  (that still leaves the
question of chips like the MIPS that can run both big- and little-endian,
but let's leave that aside for the moment.)

so what are the implications of this?  there should only be one "port"
for all the m68k platforms.  "but they can't share kernels!" you say.
I think the way this was handled for sun3 vs. sun3x is a good example
of how to start to address this.  put them in the same directory under arch,
and use config options to select which set of incompatible hardware support
you want in a given kernel.  as time goes on, more code can be made
common and moved into the shared directory for that type of cpu.
so the way I see this turning into a directory structure is:

sys
	arch
		m68k
			m68k
			sun3
			sun3x
			hp300
			mac68k
			amiga
			...
		mips
			mips
			pmax
			hpcmips
			sgimips
			cobalt
			...
		arm
			arm
			arm32
			arm26
			dnard (or shark or whatever)
			cats
			riscpc
			...

you get the idea.  as for kernels, we can start with multiple GENERIC
kernels for m68k, one for each of the sets of incompatible hardware
support.  gradually, code could be moved from platform-specific areas to
more common areas as people have the time and motivation to abtract
the commonality.  eventually we might even be able to make a GENERIC
that would boot on all of the m68k's, which I think would be neat.

"but not all userland is shared between eg. hp300 and sun3 anyway!"
that's true, so let's look at which programs aren't shared.
off the top of my head, these are disklabel and installboot.
is there anything else?  for these two problems, really it be great
if they could be used on any platform to manipulate disks for any
platform.  so even though they are currently platform-specific,
they should be made common with the common version knowing how to
target any platform (ie. select a target platform with a command-line
argument).  I'm planning on working on this once I've gotten
more rough edges off of UBC (but anyone is welcome to start first).

the other issue seems to be that the installation process for
different "ports" is different for some reason.  other than
the issues convered by the two tools above (disk partitioning
and making a disk bootable), what reason is there for this
to vary between ports?  (I'm not so familiar with installation
issues so there might be something that I don't know about.)

what about mipsel vs. mipseb?  I don't know what code (if any)
is actually endian-specific that isn't already handled via
some other mechanism.  I'm sure people will point them out if
there are any.  if there aren't, this seems like a simple build
issue that we could parameterize with a make variable.  I'm
probably overlooking something here.

the objections people have to merging more platforms into fewer "ports"
have always seem to amount to "that obviously won't work".  but what's
being proposed instead isn't actually much different.  under the sys/cpu
scheme, would there be "cpumasters" who own the cpu/foo directories?
that wouldn't make much sense.  all of the mips portmasters would
cooperate to manage the cpu/mips subtree.  in the scheme I described
above, there wouldn't be a single "mips" portmaster, but anyone who
is working on the code which supports a mips-based platform would be
allowed (encouraged? expected? required?) to work on the common mips code
as well as the code which supports their particular flavor of hardware.

so in summary, I think we really ought to be moving towards fewer ports,
not more, and I haven't seen any good reason given for why this is
undesirable or even harder than what we do now.  I sorta get the idea
that people think having more ports will mean that port maintainers
will break each other's ports less often, but I don't believe that's true.
or if it is true, then we're not sharing enough code between ports,
which is also bad.

-Chuck


On Thu, Dec 21, 2000 at 03:15:05PM +0000, Ben Harris wrote:
> [ Apologies if I'm reducing the number of lists this goes to -- I read
>   most NetBSD lists through a mail-to-news gateway, and messages sent to
>   multiple lists confuse things. ]
> 
> In article <20001221145321.A16756@theory.cs.uni-bonn.de> you write:
> >But you still build everything anew, while currently, I run a make build
> >and forget the machine until everything is ready, and it only needs
> >90%+10%+10%+10% instead of 100%+100%+100% build time.
> 
> Assuming you're talking about the userland code here, I see this as a bug in
> the build system.  There are several NetBSD/powerpc ports, several
> NetBSD/mipsel ports and many NetBSD/m68k ports.  Even if we don't split
> NetBSD/arm32, there will eventually be two NetBSD/arm ports.  Trying to
> collapse each of these groups of ports into one, with a shared sys/arch
> subdirectory, a shared install mechanism and a shared portmaster seems
> ludicrous.
> 
> The right solution is surely to fix the build system so that it can skip
> over chunks of the tree that have already been built for a given
> MACHINE_ARCH, or indeed for all machines, rather than to smush the world
> until it stops confusing the build mechanism.
> 
> -- 
> Ben Harris                                                   <bjh21@netbsd.org>
> Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>