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