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

[Zeeshan Ali (Khattak)]

On Mon, Feb 18, 2013 at 7:05 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Mon, Feb 18, 2013 at 04:03:12PM +0200, Zeeshan Ali (Khattak) wrote:
>> On Mon, Feb 18, 2013 at 3:20 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
>> > On Sat, Feb 16, 2013 at 05:38:27AM +0200, Zeeshan Ali (Khattak) wrote:
>> >> Actually you and I both missed something important here: The libosinfo
>> >> db doesn't just come from libosinfo. We allow downstream and apps to
>> >> add to the DB. They can as well add new device drivers.
>> >
>> > Currently install scripts only support one format, so there is not much
>> > point for downstream to add a driver in an unsupported format.
>>
>> 1. With my patches, winxp will support one format for preinstall
>> drivers and another for postinstall.
>
> Hmm true, but both formats are of the type 'copy all listed files to the
> installation disk, and libosinfo will know to make use of it'

? If you add a postinstall driver to winxp that does not provide .cmd
file, you can be sure that your driver will not be used. Similarly, if
you add a pre-installable driver, a executable/cmd file isn't what the
script is expecting.

>> 2. How do apps find out which format is supported if they want to add
>> more drivers? Currently, only by looking at the scripts themselves
>> (which is more like asking them to read the source). It would
>> definitely be desirable to have a simple API like this to query such
>> info.
>
> See my answer to your point 1.

Yes and I answered. If anyone adds driver(s) to DB, they really do
need to know which format it must be in. Without APIs, they'll have to
read the script template to figure it out.

>> > I don't even
>> > know if you can append easily information to an existing OS (as opposed to
>> > overwriting an existing OS) to add a driver while keeping the existing
>> > instal script.
>>
>> Its pretty easy but even if its not, that is pretty irreverent. The
>> relevant fact is that we support it. If its not easy, we can talk
>> about it in another thread.
>
> I'd s/we support it/we want to support it
> I agree this is something that should be working, however this has seen so
> little use that there are probably various issues with doing that.

We use it in Boxes for logos and I find it very likely that we'll need
to use this downstream in RHEL (actually for drivers in fact).

>If such
> a format thing is needed, that would just be another rough edge ;) But
> until we add a driver format that is not of the type 'copy all files to
> destination disk', I don't think we should try to provide an API for driver
> formats.

We already have the case of preinstallable and postinstallable drivers
for the same OS in two different formats so that already shows the
need for such an API.

>> > Adding another driver format requires patching libosinfo (schema/parsing
>> > changes), so we'll know about it if that's needed, and then we can think
>> > talk again about this API in light of this new format.
>>
>> That is also not true. Any part of the DB can be extended, including
>> addition of scripts and OSs.
>
> Emphasis on the "format" part of "Adding another driver format", you seem
> to have read "Adding another driver" here.

True. My appologies.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124