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

[Rafal Jaworowski <raj@semihalf.com>]

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