On Tue, 18 Dec 2007 23:40:47 +0100 Rafal Jaworowski raj@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