[ag-automation] [RFC] OSADL Board Support Package Specification, Revision 0.1

[Wolfgang Denk]

Dear Robert,

in message <20060912150514.GU10251 at pengutronix.de> you wrote:
> 
> we have put the first draft of the OSADL Board Support Package
> Specification on the web server for public review.

Thanks a lot.

Here a few initial comments:

* BSP Definition:

  IMHO the most obvious reason for creating a BSP does not get
  mentioned: implementing all the  board-specific initializations and
  configurations to get Linux running on a specific hardware.

  I tend to disagree with your statement that it "is usually the need
  to extend the Vanilla Linux Kernel"; this is not our experience. In
  most cases just hardware-specific configuration to the kernel is
  needed. Extensions only come in to play as far as driver support is
  required.

  Also I think it would be a good idea to clearly differentiate
  between the requirements we want to impose to enable easy maitenance
  of a BSP and the requirements that arise from the GPL: normally, the
  end user expects a ready-to-use source tree, and this is IMHO what
  is required by the GPL. The fact that we (additionally) require
  patches against a clearly identifyable version of a standard kernel
  tree is a different, new thing.

* Kernel Modifications Rules

  A better definition of "vanilla  kernel  version"  is  needed.  For
  example,  it  is  not  clear  if  "2.6.18-rc6-gbd314d97"  is such a
  "vanilla" version, or  if  I  have  to  use  "2.6.18-rc6"  or  even
  "2.6.17" instead.

  "Patches are never allowed to delete parts of the tree" - please
  delete this. When I find I can refactor identical code used by
  several BSP I maintain into common code I should of course be able
  to get rid of the resulting dead files.

  "Files already existing in the vanilla kernel tree are not allowed
  to be replaced by a file with the same name but other contention." -
  please delte this. This is exactly what a patch does: changing the
  content of existing files.

  " Patches should not destroy other architectures or sub
  archtectures." - please delete this; it is redundant to the
  statement " Patches are never allowed to delete parts of the tree,
  especially not other architectures." above.

  "In rare cases there may be a need to break other platform code due
  to project reasons; patches which  do  so  have  to  be  explicitly
  marked  as "uggly hack"." - I think we should not explicitely allow
  for such exceptions. Also, "ugly  hack"  comments  is  IMHO  not  a
  standard  way  to  mark  such  code,  at least I am not aware of it
  generally being accepted and/or documented for kernel code.

* Levels of Conformance

  I have to admit that I cannot make heads nor tails of this. I would
  expoect  that  the  listed  4  confoirmance  levels  are   somewhat
  hierarchical, so that for example improvements to the code could be
  added to reach better conformance levels - however, I find that the
  descriptions for the 4 levels are pretty unrelated.

  Also, I disagree with the "does not touch generic files"
  requirement. For any BSP it is a standard thing to touch generic
  files, for example you will probably always want to patch
  arch/*/Kconfig to add a configuration option for your new board.

* Toolchains

  "One important part of a BSP is the toolchain used to compile the
  kernel" - I disagree. The toolchain has *nothing* to to with a BSP.
  These should be completely orthogonal, and I would like to see an
  explixcit requirement, that any BSP that reaches any OSADL
  conformance level does *not* depend on any specific tool chain. On
  controary, it should be required that any known-to-be-working
  toolchain for this architecture and kernel version can be used.

  I suggest to remove the toolchain section from the BSP document.



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Speed of a tortoise breaking the sound barrier         = 1 Machturtle