[U-Boot-Users] [PATCH] Update to stand alone program feature

[Jeff Mann]

> Technically, you write: "function_no is defined by the enum  
> type  of _exports.h, so it must be included in the stand 
> alone program."
> 
> I willreject this patch. As the name  "_exports.h"  suggests, 
>  it  is intended to contain implementation internals that are 
> not supposed to be used by application code.

Let me clearify (then I can update the doucmentation if we come up with
a better description). As you know, the list of functions in _exports.h
is used to create the enumerated type: XF_get_version 0, XF_getc 1,
XF_tstc 2, ... Etc. So as long as the user has included exports.h or has
uses some other means to identify the function's jump table inxex number
in his/her stand along program, he can know if that function is
available in u-boot. 

This is useful when, for exmaple, a company builds boards both with and
without NAND support. A stand along program will be able to know that
that board was loaded with a u-boot that did not incude NAND support. 

> Also, please assume that "_exports.h" is under GPL...

I thought it got used by exports.h to "define interfaces to U-Boot."
thought these files are not listed below, wouldn't it be necessary to
use these in order to decode the jump table? I do not mean to open up
the licensing can of worms again, but knowing XF_foobar enumerated
values are necessary to use the jump table, right? 

>From COPPYING file:
"NOTE! This copyright does *not* cover the so-called "standalone"
applications that use U-Boot services by means of the jump table
provided by U-Boot exactly for this purpose - this is merely
considered normal use of U-Boot, and does *not* fall under the
heading of "derived work".

  The header files 'include/image.h' and 'include/asm-*/u-boot.h'
define interfaces to U-Boot. Including these (unmodified) header
files in another file is considered normal use of U-Boot, and does
*not* fall under the heading of 'derived work'."

-JM