Subject: Re: CVS [email-masked]: linux

From: Geert Uytterhoeven <[email-masked]>
Date: Fri, 13 Jun 2003 16:19:46 +0200 (MEST)

On Fri, 13 Jun 2003 [email-masked] wrote:
> 	Consolidate all the MIPS PCI code in arch/mips/pci.

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.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email-masked]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Jun 2003 16:30:49 +0200

> I agree that extracting common parts and cleaning up the code is a good idea,

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

---

From: Jun Sun <[email-masked]>
Date: Fri, 13 Jun 2003 10:33:40 -0700

> 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

---

From: Geert Uytterhoeven <[email-masked]>
Date: Fri, 13 Jun 2003 20:56:48 +0200 (MEST)

> chipsets instead of another place for board-specific code to live.

That's fine!  I just didn't realize there was that much chipset sharing between
the different boards. E.g. for Vr41xx, all board code is already in subdirs
within the vr41xx directory.

So in the future we may see something like this:

  arch/mips/chipset1/...
           /chipset2/...
	   /...
	   /board1/...
	   /board2/...

where the board* directories contain the glue code for the specific boards?

Gr{oetje,eeting}s,

						Geert

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 13 Jun 2003 22:28:03 +0200 (MET DST)

> where the board* directories contain the glue code for the specific boards?

 It looks as a good idea, although possibly an intermediate directory
would be desireable not to clutter arch/mips too much.  E.g:

  arch/mips/platforms/platform1/...
                     /platform2/...
            ...
  arch/mips/chipset/chipset1/...
                   /chipset2/...

I assume by "chipset" you mean the lone system controller or host bridge. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Dan Malek <[email-masked]>
Date: Fri, 13 Jun 2003 17:00:12 -0400

>   arch/mips/platforms/platform1/...

 From my experience with other architectures, fewer intermediate
directories are often useful, for example:

	arch/mips/platforms/board_and_chip_files

allows a maximum amount of code sharing and minimal duplication.
When you have lots of lower level directories, you often have
many identical files in them that should be shared, but are not,
causing support/update challenges.  For example:

	arch/mips/platforms/mfg_board_common.[ch]
	arch/mips/platforms/mfg_board_type1.[ch]
	arch/mips/platforms/mfg_board_type2.[ch]

keeps all manufacturer shared code in one place, and the board
files could be quite small.  I have the specific case right now
with a board vendor that has about six similar boards, all in
separate directories like this:

	arch/mips/au1000/board1/file.c
	arch/mips/au1000/board2/file.c
	arch/mips/au1000/board3/file.c

where the code is all identical in those files.  My first move is
going to be consolidation of all of the "board" directories into a
single "manufacturer" directory just to eliminate the overhead of
keeping all of these files consistent on updates.  Then, I'm just
going to prefix the board type to the unique file names.  I find
this much easier to maintain and to share code.  Common sense
file names using a standard manufacturer/board name prefix makes
the files just as easy to identify as separate directories.

It would be nice to see the defconfig files in their own directory,
that would be the single most useful way to eliminate some clutter :-)

Thanks.

	-- Dan

---

From: Jun Sun <[email-masked]>
Date: Fri, 13 Jun 2003 14:44:25 -0700

> 	arch/mips/platforms/mfg_board_type2.[ch]

Congradualtions!  You will have roughly about 950 files under that
directory.

Even with good effort to combine files and promote sharing, I think
you will still have quite some.

I think having another directory layer under arch/mips/platforms
shouldn't be too bad, (although I like arch/mips/machines better).  

We can use some scheme like Geert was proposing, i.e., named after
boards and chipsets.  Hack, I think even naming after board vendor
is acceptable.

> that would be the single most useful way to eliminate some clutter :-)

I second on this.

Jun

---

From: Jun Sun <[email-masked]>
Date: Fri, 13 Jun 2003 14:45:46 -0700

> I assume by "chipset" you mean the lone system controller or host bridge. 

I agree.

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Jun 2003 01:23:15 +0200

> boards and chipsets.  Hack, I think even naming after board vendor

Chipsets are a too coarse granularity to structure things these days.
Modern chipsets integrate a large number of logically independant
functionality.  Frequently such chipsets are ASICs which consist of
various logically independant functions licensed from several sources
and possibly multiple chipset / ASICs are being used in a single
system.  The world just isn't that simple ...

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Sat, 14 Jun 2003 20:48:22 +0200 (MET DST)

> allows a maximum amount of code sharing and minimal duplication.

 What prevents one from sharing code from different directories?

> where the code is all identical in those files.  My first move is

 IMO file.c should me moved up one level or to arch/mips/au1000/lib.

> the files just as easy to identify as separate directories.

 Identification is not a problem.  Logical separation is.  Directories
were invented for a reason.

> that would be the single most useful way to eliminate some clutter :-)

 It sounds reasonable.  The generic defconfig of course has to be left
where it is now.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Sat, 14 Jun 2003 20:55:45 +0200 (MET DST)

> system.  The world just isn't that simple ...

 What's the deal?  E.g. for a PCI chip we can have a separate file for
each function.  And anything that is not related to a system's core, i.e. 
a peripheral device, belongs to drivers/whatever anyway.