On Tue, Dec 4, 2012 at 1:01 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Tue, Dec 04, 2012 at 11:47:06AM +0100, Christophe Fergeau wrote: >> On Mon, Dec 03, 2012 at 06:30:18PM +0200, Zeeshan Ali (Khattak) wrote: >> > I agree with you that it would be nice to avoid this mapping all >> > together but if its not possible/feasible, these mappings should be in >> > the XML like rest of OS specific stuff. >> >> I could do that, but the C code would still have to match the regex with >> data from the table, which is only useful to Windows anyway, so the C code >> would still be somehow Windows specific. > > Looking at the problem more broadly, I believe we have a general need > to have OS specific data maps for several installation aspects. In the > OsinfoInstallConfig class we have setters for the keyboard layout, > language, AFAICT, we already have solution for those. It involves maps but in the xml itself. > and timezone. Oh, I had forgotten that needs mapping too. > The values required for each of these setters > is really OS-specific. To properly isolate apps from this, we need to > have a data map concept, so libosinfo defines a canonical set of keyboard, > language and timezone values, and then maps to the OS-specific values > internally. > > This ISO language extraction is just another example of the need for > a general datamap capability IMHO, and while we only see it for Windows > currently, I would not be suprised if other OS we encounter in the future > need it too. > > I did actually start hacking up datamap support, but never finished it. Not sure there is really a need to do mapping in the code for at least the installers. Apart from app developers, we need to think about non-C-hackers to be able to add data (including installer script templates). If we put this in C, anyone wanting to add a new OS and/or its installer will then be required to have to hack on libosinfo in C. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list