Izumi Tsutsui wrote:
> In article <44029233.5090404@damore.org>
> garrett@damore.org wrote:
>
>   
>> It strikes me that the idea that arc,evbmips,algor,cobalt,hpcmips, etc.
>> are all so different as to require different "ports" is a bit bizarre,
>> especially when the port includes a large part of software that is *not*
>> included in the kernel.
>>
>> I.e. why are we building n-different (where n > 6 and growing) different
>> copies of userland, that are basically identical except for the results
>> returned by uname?
>>     
>
> In the perfect world, all ports which have the same ${MACHINE_CPU}
> should have the same userland binaries. Actually we've already shared
> all X clients and games sets. The only reason why we have different
> base.tgz and comp.tgz is that some binaries (disklabel(8), fdisk(8) etc.)
> have ${MACHINE} specific #ifdefs, which should be rewritten to use
> uname(3) and if/else clauses at runtime.
>   
There was some note on ICB that a few other bits, /usr/mdec are machine
dependent as well.  It was suggested that we could split base.tgz into
base and base-md.tgz.  Then only the truly machine specific bits would
need to be non-shared.   etc.tgz probably needs to remain machine
specific because of ttys, but I would *love* to have the rest of it
(especially the majors and MAKEDEV bits) to be the same so that you
would have the same major numbers across all the same ${MACHINE_CPU}.
>   
>> Is there some compelling reason why we couldn't have e.g. mips32 as a
>> "port", and then have e.g.:
>>
>> sys/arch/mips32/alchemy/...
>> sys/arch/mips32/cobalt/...
>>
>> directories and kernel config files like ALCHEMY, DBAU1550, COBALT, etc.
>>     
>
> Some possible reasons are on ${MACHINE} specific part:
> - disklabel, which may have some compatibility stuff with the "native" OS
>   (OMS400 requires MBR support but current evbmips doesn't have it BTW)
>   
Yeah, but there is no disk support yet either -- i.e. you probably need
compact flash & pcmcia to work first.  right now we don't even have that.
> - bootloader binary (depends on the firmware)
> - installation note (ditto)
>   
yes.
> etc.
>
>   
>> We already have something like this within e.g. "evbmips", but it could
>> be extended to cover pretty much any R4Kish ports, I'd think.
>>     
>
> evb* ports are some exceptions, IMHO.
>
> There is no particular difinition what ${MACHINE} or "port" is,
> but in general the "port" means machines which can be covered by
> the single GENERIC kernel. I.e. machines whose diffences are
> small enough and dependent code can be switched at runtime.
> Actually, old arm32 port has been split into three independent
> ports, acorn32, cats and shark.
>
> But in this difinition we'll have too much ports even for
> a rare single architecture, so evb* ports cover all such machines.
>   
yes, except one definition i've heard for evb* ports is "Evaluation
boards".  There are production boxes that share so much in common that
it is silly to have them have their own port -- e.g. MTX-1 and OMS400
are not eval boards at all, but are basically derivative designs.  Right
now they are in evbmips even though they're production designs.
>   
>> Is there some compelling reason to keep each port in its own directory
>> tree that I don't understand, or are we doing it this way just be cause
>> that's the way it has always been done?
>>     
>
> For the kernel part, MD directly should have only MD stuff and
> all code which can be shared among all mips ports should be in
> arch/mips. That's all, I think.
>   
the problem is that we have e.g. bus_space and pci_machdep and such that
*could* pretty much be shared (esp. the header files) but instead of
having a common set, each port seems to have its own.  I can't
understand why this is.  It seems to me like it increases the risk of
port-specific regressions and increases maintenance costs.
>   
>> And if the latter case is true, is there a reason we couldn't/shouldn't
>> change it?
>>     
>
> It depends how we can handle MD stuff (I could be wrong though).
>
> There are also some historical reasons because NetBSD may be
> the first OS which supports machines which have the same cpu
> but differnt manufactures.
> (mips ports are still better than m68k ports)
>   
ok.  Btw, it was pointed out that maybe this conversation belongs on
tech-kern.

    - -Garrett
> ---
> Izumi Tsutsui
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191