On Mon, Feb 18, 2013 at 7:05 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> 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@xxxxxxxxxx> 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 _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
