[U-Boot] want to clarify a couple things about vendor common/ directories

[Robert P. J. Day]

On Wed, 13 Apr 2016, Wolfgang Denk wrote:

> Dear Robert,
>
> In message <alpine.LFD.2.20.1604130835360.4548 at localhost.localdomain> you wrote:
> >
> >   (in fact, i can see that of the several vendors that have
> > common/ directories, only ti/common/ has a Kconfig file, so i'm
> > concluding that a common/ directory containing a Kconfig file is
> > more the exception rather than the norm. ti/common/ seems like a
> > special case, in that it contains just some board_detect code, and
> > its Kconfig would be explicitly sourced by the subset of ti boards
> > for which it's relevant, so that makes sense. but, as i mentioned,
> > that's the only example i see.)
>
> Kconfig stuff is still relatively new, and not many vendors update
> their code on a regular base, unless pressed into it ...

  actually, the point i was trying to make (badly) is that almost all
Kconfig files exist *outside* of vendor common/ directories, which
seems to make sense, as selection is tied more to boards, while the
common/ directories are treated simply as the source of code that is
being selected. so it makes sense (at least to me) that vendor/ common
directories will contain a Makefile and piles of selectable common
code, but not a Kconfig file.

  i was only noting that there is a single example -- board/ti/common/
-- that contains a Kconfig file, but that seems like a trivial case.

> > i suppose it might have been possible for the build process to add
> > the common directory to the include search path for header files,
>
> I think we tried this (many, many years ago), and it caused all
> kinds of problems; the vendor specific code is often... umm...
> vendor specific.

  it took only a few more minutes to realize that adding that
directory to the search path would be a really bad idea.

> >   finally, in terms of pulling in common source files, i'm just
> > going to be appalled by the occasional form of this:
> >
> >   amcc/bubinga/flash.c:#include "../common/flash.c"
> >   amcc/walnut/flash.c:#include "../common/flash.c"
> >   amcc/bamboo/flash.c:#include "../common/flash.c"
> >   amcc/luan/flash.c:#include "../common/flash.c"
>
> I share your dislike...
>
> > or is textual inclusion of source files from a common directory
> > acceptable practice? i normally really dislike this, but is doing
> > that in this specific context in u-boot considered acceptable?
>
> This is very, very old code. It would not be accepted these days.
> And if you look closer, the code is totally redundant, as the
> standard CFI driver would probably work on most of these boards - if
> not everywhere.

  good. i'm bringing a pile of legacy u-boot code up to date and some
of it does this, so i was wondering if this was some approved coding
style for u-boot. i'm relieved that it isn't, so i can refactor the
code and get rid of that.

  onward ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================