[Libosinfo] [PATCH] Add Slackware metadata

[Christophe Fergeau]

Hi,

On Thu, Sep 11, 2014 at 08:10:15PM +0200, Matteo Bernardini wrote:
> > i486 does not exist in data/schemas/libosinfo.rng which causes
> > test-xml-validate to fail (when running make check).
> > You could add the new value there, but I'm not sure how much existing
> > code hardcodes the known values already. Slackware binaries are exactly
> > i486 binaries ? They won't work on an i386 but an i686 is not required?
> 
> Yes, they are built with "-O2 -march=i486 -mtune=i686", so binaries
> actually run fine on i486.
> I think there should be no probs either in switching arch to i686 if
> it's safer, also because the use cases for virtualizing i486 that I
> can think of are very few... if someone complains it also can be
> changed again later...
> let me know the way you prefer.

I'd go with i686 as some client code is already explicitly testing for
i386/i686/x86_64.


> > All the 64 bit images starting with 13.1 seem to be using Slackware64
> > here. This is good as otherwise libosinfo would not be able to tell the
> > difference between a 32 or 64 bit image.
> 
> Yes, my bad: I'll change the xml accordingly...
> Just to let you know the logic behind the patch, I added versions from
> 13.0-onward as they are the ones still supported (there's no defined
> eol_date): what do you think it's better, to start from 13.1 or to add
> another field to the xml to let it recognize the arch (a suggestion of
> the field to use would be appreciated ;) )?

I can't see a field which libosinfo can parse already and which would
be different between the 32 and 64 bit images, so I don't think we can
make the difference between the 2 images unfortunately :( (maybe we
could add support for parsing 'Volume size is: 1914167' which is
different). For now I guess you can keep the data as it is, or remove
the volume ids for one of the 2 arches.

> 
> >
> > I would also add some information about the supported virtio devices,
> > but this can be added later.
> 
> Ok, I'll have a look.
> To explain, it's just that I was adding libosinfo to slackbuilds.org
> (Slackware's third party repository of build scripts) as a dependency
> of the newer virt-manager and I tried to do something to let it
> support also Slackware itself (with some debugging help from Robby
> Workman and Willy Sudiarto Raharjo)...
> Then I thought that maybe this stuff could have been useful also upstream...
> 
> Any hint to enhance slackware support is obviously welcome! :)

I'd look at the fedora.xml.in file and reuse some of the <devices>
entries which are in there depending on how recent the kernel in the
slackware releases are. But this should work fine even without these
devices, adding them may improve performance of the VM, or integration
with the client OS.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libosinfo/attachments/20140912/96126b49/attachment.sig>