On Fri, Jun 13, 2003 at 04:30:49PM +0200, Ralf Baechle wrote:
> On Fri, Jun 13, 2003 at 04:19:46PM +0200, Geert Uytterhoeven wrote:
> > Is this really a good idea? You moved board-specific code (`everything
> > related
> > to one board in a single dir') into one directory? So for a new port, you
> > now
> > have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.
> > I agree that extracting common parts and cleaning up the code is a good
> > idea,
> > though.
> It's just toooo much to do in one step, expect forther moving of code
> to get everything to it's final place. The amount of code that was
> being duplicated was just insane and trying to sort boards by chipset
> was part of the evil. So MIPS's boards may come with one of several
> PCI chipsets and the Lasat systems may have either a NEC Nile4 or a
> Galileo 64120 chipset. Result? Each was duplicating the code to support
> both chipsets into it's arch/mips/foo/ code. Similar things with code
> to support various firmware such as PMON etc.
> Anyway, suggestions welcome,
Ralf and I chatted a little before the change. I think this _may_ be
a good thing. It does not hurt to give it whirl first.
I was trying to promote chipset based grouping, like gt64120/ or ddb5xxx/,
but apparently not everybody likes that. People are still going with
company or machine based grouping, which makes chipset code sharing impossible.
I also realize that chipset based grouping (and sharing) requires more
design and synchronization between developers, and thus probably harder
to do. So in that sense, arch/mips/pci, as a less restrictive mechnism
for sharing, might work better.
So I like to view arch/mips/pci as some PCI library routines for
chipsets instead of another place for board-specific code to live.