Libguestfs - Nov 2015 - Re: packaging virtio-win (was: Re: [PATCH] v2v: virtio-win: include *.dll too)

On Mon, Nov 23, 2015 at 08:26:10PM +0300, Roman Kagan
wrote:
> On Thu, Nov 19, 2015 at 09:45:36PM +0300, Roman Kagan wrote:
> > On Wed, Nov 18, 2015 at 11:31:17PM -0500, Li Jin wrote:
> > > > > > In any case the *.inf files don't seem to have
any distinguishing
> > > > > > feature which would allow us to check this.
> >
> > Catalog files are pkcs7 containers with multi-layered nested ASN.1
> > structure
> [...]
> > So it looks like yes, there's certain data in there which can be
used to
> > match it against the exact Windows version; not sure what to do with
all
> > this, though.
> 
> Having given it some more thought and having discussed that with
> colleagues who do various things with the drivers, like generating
> unattended install helpers or just manually installing drivers into
> guests, I'm now of the opinion that neither libguestfs nor any other
> user of the drivers should look inside the driver files in order to
> match them against the guest OS, because it's hard for programs and
> unrealistic for humans.
> 
> I tend to believe it should be the responsibility of the driver packages
> to lay out the drivers in a directory structure that both humans and
> programs could grok easily and that wouldn't change once established;
in
> a sense this would be both an API and a human interface.
> 
> If I were to lay it out I'd group the stuff by guest OS, so that for a
> particular guest a single entity -- a directory tree or a pre-created
> ISO or floppy image -- would contain all that's needed for this guest
> and nothing else.  This would allow separation of concerns, so that
> actors who bring the stuff into the guest wouldn't need to care about
> what's inside, and actors involved with its installation wouldn't
need
> to know how to find the right one.
The good news is that this is what we do right now.
> E.g. from this POV the way drivers are stored in RHEL7 virtio-win
> package on the *filesystem* looks OK, the way they are stored in the
> *ISO image* in the same package doesn't.
> 
> As for naming one can stick with what's being used in that virtio-win
> rpm, i.e.
> 
> {amd64,i386}/Win{XP,2003,2008,2008R2,2012,2012R2,7,8,8.1}
>
> or switch to the names passed to inf2cat in its /os parameter, i.e.
> 
> XP_X86,Server2003_X86,...,8_X64,Server8_X64,6_3_X86,6_3_X64,Server6_3_X64
>
(https://msdn.microsoft.com/en-us/library/windows/hardware/ff547089(v=vs.85).aspx)
> 
> Whatever convention is chosen it needs to be followed thereafter.
Yup - very important that once we decide what the naming convention is
going to be, we stick with it.  Moving drivers around or using ad-hoc
naming schemes causes churn in virt-v2v and probably other projects
too.
> The main problem with this proposal is that I don't know how to
> implement it: there are multiple vendors of virtio-win packages, and,
> for licensing reasons, they don't even share the source code, so
it's
> unclear who could own this convention and enforce it on others.
I guess that virt-v2v will have to deal with this with more special
rules.
> I'd appreciate any thoughts or suggestions on how to proceed from that
> and whether it's worth it at all.
Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

On Tue, Nov 24, 2015 at 01:07:03PM +0000, Richard W.M. Jones
wrote:
> On Mon, Nov 23, 2015 at 08:26:10PM +0300, Roman Kagan wrote:
> > Having given it some more thought and having discussed that with
> > colleagues who do various things with the drivers, like generating
> > unattended install helpers or just manually installing drivers into
> > guests, I'm now of the opinion that neither libguestfs nor any
other
> > user of the drivers should look inside the driver files in order to
> > match them against the guest OS, because it's hard for programs
and
> > unrealistic for humans.
> > 
> > I tend to believe it should be the responsibility of the driver
packages
> > to lay out the drivers in a directory structure that both humans and
> > programs could grok easily and that wouldn't change once
established; in
> > a sense this would be both an API and a human interface.
> > 
> > If I were to lay it out I'd group the stuff by guest OS, so that
for a
> > particular guest a single entity -- a directory tree or a pre-created
> > ISO or floppy image -- would contain all that's needed for this
guest
> > and nothing else.  This would allow separation of concerns, so that
> > actors who bring the stuff into the guest wouldn't need to care
about
> > what's inside, and actors involved with its installation
wouldn't need
> > to know how to find the right one.
> 
> The good news is that this is what we do right now.
> 
> > E.g. from this POV the way drivers are stored in RHEL7 virtio-win
> > package on the *filesystem* looks OK, the way they are stored in the
> > *ISO image* in the same package doesn't.
> > 
> > As for naming one can stick with what's being used in that
virtio-win
> > rpm, i.e.
> > 
> > {amd64,i386}/Win{XP,2003,2008,2008R2,2012,2012R2,7,8,8.1}
> >
> > or switch to the names passed to inf2cat in its /os parameter, i.e.
> > 
> >
XP_X86,Server2003_X86,...,8_X64,Server8_X64,6_3_X86,6_3_X64,Server6_3_X64
> >
(https://msdn.microsoft.com/en-us/library/windows/hardware/ff547089(v=vs.85).aspx)
> > 
> > Whatever convention is chosen it needs to be followed thereafter.
> 
> Yup - very important that once we decide what the naming convention is
> going to be, we stick with it.  Moving drivers around or using ad-hoc
> naming schemes causes churn in virt-v2v and probably other projects
> too.
> 
> > The main problem with this proposal is that I don't know how to
> > implement it: there are multiple vendors of virtio-win packages, and,
> > for licensing reasons, they don't even share the source code, so
it's
> > unclear who could own this convention and enforce it on others.
> 
> I guess that virt-v2v will have to deal with this with more special
> rules.
> 
> > I'd appreciate any thoughts or suggestions on how to proceed from
that
> > and whether it's worth it at all.
Apparently I failed to inspire anybody who can affect the driver
packaging layout :)  Let me try again.

Do I get it right that the way virtio-win is packaged for Fedora and
RHEL is driven by the scripts at

https://github.com/crobinso/virtio-win-pkg-scripts

and I should be submitting patches or pull requests to it?

Or should the layout be determined only by the build machinery at

https://github.com/YanVugenfirer/kvm-guest-drivers-windows

and I should be direct my submissions that way?

Or any combination of the above?

Also does anybody know this is done in SUSE?

Any help would be appreciated.

Thanks,
Roman.

On Thu, Nov 26, 2015 at 08:12:41PM +0300, Roman Kagan
wrote:
>On Tue, Nov 24, 2015 at 01:07:03PM +0000, Richard W.M. Jones wrote:
>> On Mon, Nov 23, 2015 at 08:26:10PM +0300, Roman Kagan wrote:
>> > Having given it some more thought and having discussed that with
>> > colleagues who do various things with the drivers, like generating
>> > unattended install helpers or just manually installing drivers
into
>> > guests, I'm now of the opinion that neither libguestfs nor any
other
>> > user of the drivers should look inside the driver files in order
to
>> > match them against the guest OS, because it's hard for
programs and
>> > unrealistic for humans.
>> >
>> > I tend to believe it should be the responsibility of the driver
packages
>> > to lay out the drivers in a directory structure that both humans
and
>> > programs could grok easily and that wouldn't change once
established; in
>> > a sense this would be both an API and a human interface.
>> >
>> > If I were to lay it out I'd group the stuff by guest OS, so
that for a
>> > particular guest a single entity -- a directory tree or a
pre-created
>> > ISO or floppy image -- would contain all that's needed for
this guest
>> > and nothing else.  This would allow separation of concerns, so
that
>> > actors who bring the stuff into the guest wouldn't need to
care about
>> > what's inside, and actors involved with its installation
wouldn't need
>> > to know how to find the right one.
>>
>> The good news is that this is what we do right now.
>>
>> > E.g. from this POV the way drivers are stored in RHEL7 virtio-win
>> > package on the *filesystem* looks OK, the way they are stored in
the
>> > *ISO image* in the same package doesn't.
>> >
>> > As for naming one can stick with what's being used in that
virtio-win
>> > rpm, i.e.
>> >
>> > {amd64,i386}/Win{XP,2003,2008,2008R2,2012,2012R2,7,8,8.1}
>> >
>> > or switch to the names passed to inf2cat in its /os parameter,
i.e.
>> >
>> >
XP_X86,Server2003_X86,...,8_X64,Server8_X64,6_3_X86,6_3_X64,Server6_3_X64
>> >
(https://msdn.microsoft.com/en-us/library/windows/hardware/ff547089(v=vs.85).aspx)
>> >
>> > Whatever convention is chosen it needs to be followed thereafter.
>>
>> Yup - very important that once we decide what the naming convention is
>> going to be, we stick with it.  Moving drivers around or using ad-hoc
>> naming schemes causes churn in virt-v2v and probably other projects
>> too.
>>
>> > The main problem with this proposal is that I don't know how
to
>> > implement it: there are multiple vendors of virtio-win packages,
and,
>> > for licensing reasons, they don't even share the source code,
so it's
>> > unclear who could own this convention and enforce it on others.
>>
>> I guess that virt-v2v will have to deal with this with more special
>> rules.
>>
>> > I'd appreciate any thoughts or suggestions on how to proceed
from that
>> > and whether it's worth it at all.
>
>Apparently I failed to inspire anybody who can affect the driver
>packaging layout :)  Let me try again.
>
>Do I get it right that the way virtio-win is packaged for Fedora and
>RHEL is driven by the scripts at
>
>https://github.com/crobinso/virtio-win-pkg-scripts
>
>and I should be submitting patches or pull requests to it?
Yes, that's what I use to package the drivers for RHEL.

>Or should the layout be determined only by the build machinery at
>
>https://github.com/YanVugenfirer/kvm-guest-drivers-windows
>
>and I should be direct my submissions that way?
I don't know, but if you work strictly with virtio-win-pkg-scripts it
shouldn't matter.

>Or any combination of the above?
>
>Also does anybody know this is done in SUSE?
No idea.
>Any help would be appreciated.
>
>Thanks,
>Roman.

-Jeff