[virt-tools-list] [PATCH virtio-win-pkg-scripts v3 0/2] helpers to standardize driver directory layout

Roman Kagan rkagan at virtuozzo.com
Mon Feb 8 14:23:37 UTC 2016

On Sat, Feb 06, 2016 at 06:20:42PM -0500, Cole Robinson wrote:
> Sorry for the delay, been caught up in other stuff. I'll be focusing on
> virtio-win stuff this coming week though
> I've committed these patches now. I added a few commits on top to make my
> pylint[1] setup happy. No functional changes.

Great, thanks.
I've accumulated a couple of fixes and enhancements in the meantime;
I'll rebase and post them soon.

> I'm realizing now that the input bits to make-driver-dir.py
> (virtio-win/qxl/qemu-ga windows builders from RH's internal build system)
> aren't published anywhere so there isn't any way for you to reproduce the full
> workflow for the public RPM. I'll work on getting those mirrored on
> fedorapeople.org

Actually we started putting together our stuff, too, and encountered a
number of issues I'd be interested to discuss.

1) since the drivers can only be built on a Windows machine, there's a
   need to define the artifact(s) produced on a Windows machine and used
   as source(s) for rpmbuild on a Linux machine (koji).

   We thought the most natural responsibility split (as applied to
   kvm-guest-drivers-windows) is to collect the stuff in "Install"
   subdirectories of every driver upon buildAll.bat execution in a
   single zip archive and use it as that artifact; the rest will be
   taken care of from under rpmbuild on a Linux machine.  One benefit is
   that it's going to be easy to intervene manually, e.g.  when doing
   signatures or whatever else.

   This differs from what's currently in virtio-win srpm where the
   drivers are received in a tarball whose contents was obviously
   subject to certain manipulations after building on Windows.

2) build scripts for kvm-guest-drivers-windows (haven't checked qxl yet)
   don't adhere to the conventions assumed by the scripts I posted.
   E.g. here's the relevant excerpt from Balloon/sys/packOne.bat:

if /i "%1"=="win8" goto create_win8
if /i "%1"=="wlh" goto create_vista
if /i "%1"=="win7" goto create_vista
if /i "%1"=="wnet" goto create_xp
if /i "%1"=="wxp" goto create_xp
goto error_inf2cat

if /i "%2"=="x86" set _OSMASK_=XP_X86,Server2003_X86
if /i "%2"=="x64" set _OSMASK_=XP_X64,Server2003_X64
goto run_inf2cat

if /i "%2"=="x86" set _OSMASK_=Vista_X86,Server2008_X86,7_X86
if /i "%2"=="x64" set _OSMASK_=Vista_X64,Server2008_X64,7_X64,Server2008R2_X64
goto run_inf2cat

if /i "%2"=="x86" set _OSMASK_=8_X86
if /i "%2"=="x64" set _OSMASK_=8_X64,Server8_X64
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" %INST_ARC%
goto run_inf2cat

inf2cat /driver:..\Install\%INST_OS%\%INST_ARC% /os:%_OSMASK_%

   as a result

   a) there are distinct builds for XP and 2003, but they both are
      marked as matching both XP and 2003; same problem for Vista/2008
      and Win7/2008R2
   b) there's no build marked as matching Win8.1, 2012R2 and Win10

   We have an engineer tasked with sorting this out (and submitting the
   fixes upstream of course) but ATM the scripts won't produce the
   complete and consistent driver set.

3) current virtio-win package includes several loosely related packages:
   virtio drivers, qxl, qga; we add our own, too.  They have independent
   release cycles and build procedures (e.g. qga builds nicely with
   mingw on Linux and can be turned into a normal rpm suitable for
   shipping in e.g. Fedora)

   Therefore we're considering splitting the rpm into several
   independent ones with the stuff installed onto the host filesystem as
   a directory structure; the iso and floppy images would be generated
   from that right on the host (e.g. by rpm triggers or by a tool like
   supermin) rather than brought in pre-generated.

Comments welcome,

More information about the virt-tools-list mailing list