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:
> 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:
> 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:
> 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: email@example.com, PGP key available +