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?
- 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.
- 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.
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.
Rafal