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

[Rafal Jaworowski <raj@semihalf.com>]

Haavard Skinnemoen wrote:
> I'm sorry, but I really hate this stuff.
> 
>   * 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.

>   * In other words, do we really _want_ a "stable API"?

Depending on the definition of "we", yes :-) Besides that we need a stable API
for FreeBSD purposes, I'm sure U-Boot as a whole benefits from improvement in
this area.

>   * What's the rationale for the "syscalls" this patch exports, and are
>     you absolutely sure the prototypes are sane? If you want a stable
>     API, you need to get it right the first time.

Per earlier explanation given by Marcel, the main purpose of these 'syscalls'
is providing a well defined and stable interface to access services that
U-Boot implements like operations on the console, networking, storage etc. The
prototypes we have now have been thought out for a while and reviewed, and I
think they are sane.

>   * 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.

>   * All syscalls are implemented as vararg functions, so it's difficult
>     to tell what arguments they take and whether or not they are being
>     used correctly from the other side of the "syscall" line. A
>     standard set of wrappers and associated header files would help, of
>     course.

There is a pseudo-signature description in the comment for each syscall that
was meant to help and document. Also, the helper wrapper you mention is
already there: it's the glue layer, which implements front-end conveniency
calls the consumer can use, but it's not mandatory and syscall can be invoked
directly.

>   * How is this really different from the existing jumptable stuff? It
>     looks like it's just a different set of exported functions. Will
>     the crufty old jumptable interface be removed at some point?
>     Presumably, the new interface is superior, so it should be. Right?
> 

The new interface is a similar mechanism, but it does not entangle external
application with configuration of U-Boot it happens to run upon. It's meant to
be more robust and extensible, but it is still initial implementation. This is
why it's optional so might be treated as experimental feature right now, but
my hope is after U-Boot-FreeBSD integration settles down, the old jumptable
approach can be retired (I volunteer to convert legacy standalone U-Boot apps
to the new scheme at that point).

Rafal