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

[Vadim Rozenfeld]

On Mon, 2016-02-08 at 17:23 +0300, Roman Kagan wrote:
> 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
> 
> :create_xp
> if /i "%2"=="x86" set _OSMASK_=XP_X86,Server2003_X86
> if /i "%2"=="x64" set _OSMASK_=XP_X64,Server2003_X64
> goto run_inf2cat
> 
> :create_vista
> 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
> 
> :create_win8
> 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
> 
> [...]
> :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 are working on reviewing virtio-win build system, mostly toward 
switching to VS2015 and adding Win10 as a build target.
Best regards,
Vadim.
 
> 
>    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,
> Thanks,
> Roman.