[Libosinfo] [v2 1/8] API to query format of device driver

[Zeeshan Ali (Khattak)]

On Tue, Feb 19, 2013 at 6:41 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Tue, Feb 19, 2013 at 03:41:18PM +0200, Zeeshan Ali (Khattak) wrote:
>> Another important point that I neglected to mention is that drivers
>> can come directly from app (without them adding/editing an XML). In
>> which case these APIs would be nice to have so they can decide whether
>> an arbitrary driver they want to install is compatible with our
>> script(s) or not. Also, if the driver installation does not work, they
>> can have some trace of what went wrong.
>
> This also means that apps will have to check that the driver they are about
> to install is in a known format before trying to use it, and fail if it's
> not. But this unknown driver format could be similar to the existing ones
> that copying all files is enough and things will just work. By adding this
> API; apps would need a change to accomodate it.

Not necessarily. They *should* use it, yes but not using these APIs
would not change anything for the apps. i-e driver installation will
not work in either case. The diff is that if they use these APIs, they
have better means to trace why the driver is not being installed.

> Maybe we'll also add an API where the library user explicitly lists the
> drivers they want to install (this would probably helps to get rid of this
> *.cmd thing). This function could do the format checks and
> error out if they are not compatible.

This sounds like a good idea (especially keeping in mind that *.cmd
issue) but we'll still need to inform app why we are erroring out.
With my proposed format/signature API in place, in the docs of the API
you are proposing above we'll direct app developers to check the
compatibility of script against the driver before trying to use them.
If they do put proper checks in place, they really shouldn't get any
errors.

> We really don't know what will be needed/not needed in the future, so let's
> not add APIs that may or may not be needed, that may be helpful or that may
> be harmful, but that apps have to use. If it proves needed in a while, it
> will still be time to add it, if it's not needed, we'll be happy not to
> have added it, and this will be less code in applications.

Well from my POV, I have given enough arguments to conclude that this
API is *probably* needed and I don't see why this API will be harmful
(you can never know for sure of course). When there is external apps
involved, its usually a bit hard to decide about usefulness of an API.
When designing public API of libraries, we need to anticipate the
needs rather than only adding API when apps ask for it.

>> BTW, if we decide to add these API then the driver signature API makes
>> as much sense to add.
>
> Actually I was surprised that you dropped the osinfo_driver_is_signed()
> patch; this one seems good to me.

And I'm a bit surprised that you find that API useful on its own.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124