[U-Boot-Users] Pull request: u-boot-freebsd
raj at semihalf.com
Tue Dec 18 23:40:47 CET 2007
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
>> 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
> "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
>> 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
> 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.
More information about the U-Boot