Frank Wille <frank%phoenix.owl.de@localhost> writes: > Greg Toxel wrote: > >> Why do we have to have so many different 'arches'? I get it that some >> processor families are different enough that one can't >> (currently/easily) build a single kernel that supports both, but I >> think we already have that, and I don't see the benefit of splitting to >> many. > > What is the disadvantage in having many ports? > Changes in the MI kernel interfaces would have to be updated in more places? Basically that each port is cognitive load, and something that should have a build.sh task in the build server that looks for failures. In the limit we'd have hundreds, and that seems unreasonable. > I'm not sure if that really would be the case. When everything is in evbppc, > you also have to check and fix several files and directories. Sure, but there are fewer things to do, I think. >> I could see ppc vs ppce (booke ppc), but I'm boggled by evbpcc >> and nasppc being different. What's the reason it can't fit in one? > > IMHO not only the CPU architecture decides about a port, but also common > aspects in the rest of the hardware (e.g. Amiga vs. Atari vs. Mac68k), > especially when you have lots of devices which only exist for a single > architecture. Also similar firmwares or bootloaders might play a role > (U-Boot, OFW, etc.). I can see that big things were are really fundamental making a port (OFW vs U-Boot) being a sensible guide. But having devices present on one board vs another seems not so important, especially if one could imagine building boards with different sets. > And yes, BOOKE is so different that I would vote for a separate port (maybe > including 440). :) But yet it's in the same port now, just with a kernel. My overall take is that if two systems can just be separate kernels in a single port, that's better than having two ports, as long as it doesn't hurt. But I haven't really been dealing with the details, so I could be off.
Attachment:
pgpHmtTPiY6Nl.pgp
Description: PGP signature