linux-mips
[Top] [All Lists]

Re: CVS Update@-mips.org: linux

To: Dan Malek <dan@embeddededge.com>
Subject: Re: CVS Update@-mips.org: linux
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Sat, 14 Jun 2003 20:48:22 +0200 (MET DST)
Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@linux-mips.org>, Linux/MIPS Development <linux-mips@linux-mips.org>
In-reply-to: <3EEA3B5C.2000201@embeddededge.com>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
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        +


<Prev in Thread] Current Thread [Next in Thread>