Re: CVS Update@-mips.org: linux

["Maciej W. Rozycki" <macro@ds2.pg.gda.pl>]

On Fri, 13 Jun 2003, Dan Malek wrote:

> >   arch/mips/platforms/platform1/...
> >                      /platform2/...
> 
>  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.

 What prevents one from sharing code from different directories?

> 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

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

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

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

> 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 :-)

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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +