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. Jun
