[U-Boot-Users] Pull request: u-boot-freebsd

[Haavard Skinnemoen]

On Tue, 18 Dec 2007 23:40:47 +0100
Rafal Jaworowski <raj at semihalf.com> wrote:

> Haavard Skinnemoen wrote:
> >>>   * What happens if changes to the API is needed? Will be keep adding
> >>>     new "system calls" every time a new limitation with the existing
> >>>     interface is found (like Linux does)?
> >> The API is versioned and consumer code is able to verify it. When we need to
> >> change/extend it, the version is bumped: that's similar how many other APIs
> >> are managed, like UNIX libs.
> > 
> > So old versions of the interface must be kept around in case
> > legacy applications need them (that's how solib versioning works,
> > IIRC.) Or do applications have to anticipate that the interface may
> > change in a future version?
> 
> If backwards compatibility is required then yes, this would be nice to have,
> but let's try not to miss the whole picture: with current U-Boot nine (9)
> standalone very simple programs are shipping, which use the jumptable
> approach. Why would they suffer with a more generic calling mechanism?

If this has been discussed before, please give me a pointer.

I think saying that "backwards compatibility would be nice to have"
oversimplifies how things work in the real world. Backwards
compatibility is something you find out that you need _later_ when lots
of applications have started using the initial, broken version of the
interface.

And I can say right away that there will be problems with the functions
you've already exported. get_sys_info(), for example, is absolutely
_horrible_. It is not extensible (caller and callee must agree on the
size of struct sys_info) and it contains just random, mostly
undocumented pieces of information about the system. This is be bdinfo
approach to passing system information all over again.

At the very least, please add a size argument.

So I think that before we export a new interface, every single export
must be discussed thoroughly. We may be stuck with them once they're
exported.

> >>>   * Both the API core and the examples are littered with external
> >>>     declarations. Can we please put such things in header files where it
> >>>     belongs?
> >> There's a couple of extern declarations that indeed could be placed in a
> >> separate header, but it's usually fine balance when to put something into a
> >> separate file (and bloat the files structure..), and in this case I decided
> >> not to for simplicity. All other externs are for accessing existing U-Boot
> >> objects.
> > 
> > "A couple"? There are sh*tloads of them.
> > 
> > As for accessing existing U-Boot objects, that's not an excuse. If a
> > global function is missing a corresponding header declaration, it
> > should be added.
> 
> I don't see this a maintenance difficulty, but if you consider this a major
> obstacle I'll try to improve thier organization.

Yeah, that would be great. Although I guess it wouldn't be fair to
place this burden on you -- there are lots of other instances all
around the u-boot tree where global functions are defined with no
corresponding header declaration.

> > Yeah, but the stubs have no associated header file, so you have to
> > declare them yourself. That's just begging for fun-to-debug problems
> > where the caller and the callee have different opinions about the
> > function signature...even more fun when the problems only show up on
> > certain architectures.
> > 
> 
> That's a valid point, I'll provide a header file with those.

Great :)

Haavard