Adding virtualbox guest driver to Fedora kernels (revisited)

[Hans de Goede]

Hi All,

Good news, the vboxguest driver has been queued for
upstream merging in char-misc-next. This just happened
so I want to wait for a couple of days to make sure
they stick and they do not get reverted for some reason.

Then I would like to add them as downstream patches
to the rawhide kernels for now, they can be dropped
once we rebase to 4.16.

So as always when making non trivial changes, my
question to the Fedora kernel team is, is adding
these as downstream patches ok?

Regards,

Hans

[Josh Boyer]

On Tue, Dec 19, 2017 at 6:03 AM, Hans de Goede <hdegoede(a)redhat.com&gt; wrote:
>  Hi All,
>
>  Good news, the vboxguest driver has been queued for
>  upstream merging in char-misc-next. This just happened
>  so I want to wait for a couple of days to make sure
>  they stick and they do not get reverted for some reason. 
Nice job!  That's been needed a long time and I'm really happy to see
your success in getting them upstream.

>  Then I would like to add them as downstream patches
>  to the rawhide kernels for now, they can be dropped
>  once we rebase to 4.16.
>
>  So as always when making non trivial changes, my
>  question to the Fedora kernel team is, is adding
>  these as downstream patches ok? 
I have no strong opinion, but I'm curious why we wouldn't just wait
for 4.16.  That seems like a natural sync point so that everyone that
provides this driver as a kmod simply stops when the first 4.16 merge
window kernel lands.  Adding them now means more coordination for
users and kmod builders and I wonder if that will cause confusion.

josh

[Justin Forbes]

On Tue, Dec 19, 2017 at 7:13 AM, Josh Boyer <jwboyer(a)fedoraproject.org&gt;
wrote:

>  On Tue, Dec 19, 2017 at 6:03 AM, Hans de Goede
> <hdegoede(a)redhat.com&gt;
>  wrote:
>  > Hi All,
>  >
>  > Good news, the vboxguest driver has been queued for
>  > upstream merging in char-misc-next. This just happened
>  > so I want to wait for a couple of days to make sure
>  > they stick and they do not get reverted for some reason.
>
>  Nice job!  That's been needed a long time and I'm really happy to see
>  your success in getting them upstream.
>
>  > Then I would like to add them as downstream patches
>  > to the rawhide kernels for now, they can be dropped
>  > once we rebase to 4.16.
>  >
>  > So as always when making non trivial changes, my
>  > question to the Fedora kernel team is, is adding
>  > these as downstream patches ok?
>
>  I have no strong opinion, but I'm curious why we wouldn't just wait
>  for 4.16.  That seems like a natural sync point so that everyone that
>  provides this driver as a kmod simply stops when the first 4.16 merge
>  window kernel lands.  Adding them now means more coordination for
>  users and kmod builders and I wonder if that will cause confusion.
>
>
>  Also worth noting, 4.16 will be the Fedora 28 release kernel, so it will 
make F28
either way.

Justin

[Hans de Goede]

Hi,

On 19-12-17 14:22, Justin Forbes wrote:
>  On Tue, Dec 19, 2017 at 7:13 AM, Josh Boyer
> <jwboyer(a)fedoraproject.org <mailto:[e-mail]>> wrote:
>  
>      On Tue, Dec 19, 2017 at 6:03 AM, Hans de Goede <hdegoede(a)redhat.com
> <mailto:[e-mail]>> wrote:
>      > Hi All,
>      >
>      > Good news, the vboxguest driver has been queued for
>      > upstream merging in char-misc-next. This just happened
>      > so I want to wait for a couple of days to make sure
>      > they stick and they do not get reverted for some reason.
>  
>      Nice job!  That's been needed a long time and I'm really happy to see
>      your success in getting them upstream.
>  
>      > Then I would like to add them as downstream patches
>      > to the rawhide kernels for now, they can be dropped
>      > once we rebase to 4.16.
>      >
>      > So as always when making non trivial changes, my
>      > question to the Fedora kernel team is, is adding
>      > these as downstream patches ok?
>  
>      I have no strong opinion, but I'm curious why we wouldn't just wait
>      for 4.16.  That seems like a natural sync point so that everyone that
>      provides this driver as a kmod simply stops when the first 4.16 merge
>      window kernel lands.  Adding them now means more coordination for
>      users and kmod builders and I wonder if that will cause confusion.
>  
>  
>  Also worth noting, 4.16 will be the Fedora 28 release kernel, so it will make F28 either
> way. 
To answer you both, I would like to get this into Rawhide now, to get
as much testing as possible, esp. surrounding the integration issues
with 3th party repos providing kmods, that needs some time to all get
figured out.

I've been discussing upgrade paths with the current 3th party repo kmod
maintainers here:
https://bugzilla.redhat.com/show_bug.cgi?id=1481630

My current line of thinking is to only enable this in Fedora 28+ and
only have a VirtualBox-guest-additions package (which will need this)
in the F28+ repos.

The downside of this is that we will need to remember to disable this
once 4.15 with downstream patches or 4.16 hits F26 / F27, I'm not sure
if there is any other such feature, we could do something like this
in the .spec (and drop it in a year from now):

# TODO: Drop this once we no longer support Fedora 27
%if 0%{?fedora} < 28
sed 's/CONFIG_VBOXGUEST=m/# CONFIG_VBOXGUEST is not set' .config
%endif

Regards,

Hans

[Justin Forbes]

On Tue, Dec 19, 2017 at 3:28 PM, Hans de Goede <hdegoede(a)redhat.com&gt; wrote:
>  Hi,
>
>  On 19-12-17 14:22, Justin Forbes wrote:
> >
> > On Tue, Dec 19, 2017 at 7:13 AM, Josh Boyer <jwboyer(a)fedoraproject.org
> > <mailto:[e-mail]>> wrote:
> >
> >     On Tue, Dec 19, 2017 at 6:03 AM, Hans de Goede <hdegoede(a)redhat.com
> > <mailto:[e-mail]>> wrote:
> >     > Hi All,
> >     >
> >     > Good news, the vboxguest driver has been queued for
> >     > upstream merging in char-misc-next. This just happened
> >     > so I want to wait for a couple of days to make sure
> >     > they stick and they do not get reverted for some reason.
> >
> >     Nice job!  That's been needed a long time and I'm really happy to see
> >     your success in getting them upstream.
> >
> >     > Then I would like to add them as downstream patches
> >     > to the rawhide kernels for now, they can be dropped
> >     > once we rebase to 4.16.
> >     >
> >     > So as always when making non trivial changes, my
> >     > question to the Fedora kernel team is, is adding
> >     > these as downstream patches ok?
> >
> >     I have no strong opinion, but I'm curious why we wouldn't just wait
> >     for 4.16.  That seems like a natural sync point so that everyone that
> >     provides this driver as a kmod simply stops when the first 4.16 merge
> >     window kernel lands.  Adding them now means more coordination for
> >     users and kmod builders and I wonder if that will cause confusion.
> >
> >
> > Also worth noting, 4.16 will be the Fedora 28 release kernel, so it will
> > make F28 either way.
>
>
>  To answer you both, I would like to get this into Rawhide now, to get
>  as much testing as possible, esp. surrounding the integration issues
>  with 3th party repos providing kmods, that needs some time to all get
>  figured out.
>
>  I've been discussing upgrade paths with the current 3th party repo kmod
>  maintainers here:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1481630
>
>  My current line of thinking is to only enable this in Fedora 28+ and
>  only have a VirtualBox-guest-additions package (which will need this)
>  in the F28+ repos.
>
>  The downside of this is that we will need to remember to disable this
>  once 4.15 with downstream patches or 4.16 hits F26 / F27, I'm not sure
>  if there is any other such feature, we could do something like this
>  in the .spec (and drop it in a year from now):
>
>  # TODO: Drop this once we no longer support Fedora 27
>  %if 0%{?fedora} < 28
>  sed 's/CONFIG_VBOXGUEST=m/# CONFIG_VBOXGUEST is not set' .config
>  %endif 
That part is pretty simple we keep a rebase-notes.txt file for
specifically these type cases. Things we need to remember to change as
we are rebasing onto older stable branches.