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