From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert P. J. Day Date: Thu, 14 Apr 2016 07:09:33 -0400 (EDT) Subject: [U-Boot] want to clarify a couple things about vendor common/ directories In-Reply-To: <20160413211931.959F0101313@atlas.denx.de> References: <20160413211931.959F0101313@atlas.denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, 13 Apr 2016, Wolfgang Denk wrote: > Dear Robert, > > In message 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 ========================================================================