All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Update to stand alone program feature
Date: Thu, 10 May 2007 11:10:44 -0400	[thread overview]
Message-ID: <464335F4.5010809@smiths-aerospace.com> (raw)
In-Reply-To: <1628E43D99629C46988BE46087A3FBB997B80E@ep-01.EmbeddedPlanet.local>

Jeff Mann wrote:
>> 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 will reject 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. 

[snip]

> -JM

What would be Really Cool[tm] would be to enhance the elf loading 
capability to resolve unresolved link addresses for the standalone 
application entry points.  Then the standalone program could be loaded 
by u-boot with the interfaces fixed up by the elf loader.  This would 
eliminate all the problems of jump tables and keeping them synchronized.

<http://www.gnu.org/software/binutils/manual/html_chapter/binutils_14.html>
<http://www.linuxjournal.com/article/1059>
<http://www.linuxjournal.com/article/1060>

Possible problems that come to mind...
* Code bloat
* The coupling between GPL u-boot and potentially proprietary standalone
     programs arguably is tighter.  In practical terms, I don't see this
     as an issue, but it really isn't my call.  I would contend this is
     similar to linux loadable device drivers and the current standalone
     programs have license to call back into u-boot - the same functions,
     simply a different interface mechanism.
* My ignorance may be making a molehill out of a mountain of work
* So many interesting things to do, so little time :-(

Best regards,
gvb

  reply	other threads:[~2007-05-10 15:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-09 15:50 [U-Boot-Users] [PATCH] Update to stand alone program feature Jeff Mann
2007-05-09 15:56 ` Jeff Mann
2007-05-09 22:24   ` Wolfgang Denk
2007-05-10 14:26     ` Jeff Mann
2007-05-10 15:10       ` Jerry Van Baren [this message]
2007-05-10 15:40         ` Jeff Mann
2007-05-10 14:47   ` Rafal Jaworowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=464335F4.5010809@smiths-aerospace.com \
    --to=gerald.vanbaren@smiths-aerospace.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.