On Tue, Dec 19, 2017 at 7:13 AM, Josh Boyer jwboyer@fedoraproject.org wrote:

On Tue, Dec 19, 2017 at 6:03 AM, Hans de Goede hdegoede@redhat.com 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

On Tue, Dec 19, 2017 at 3:28 PM, Hans de Goede hdegoede@redhat.com wrote:

Hi,

On 19-12-17 14:22, Justin Forbes wrote:

...

On Tue, Dec 19, 2017 at 7:13 AM, Josh Boyer <jwboyer@fedoraproject.org mailto:jwboyer@fedoraproject.org> wrote:

On Tue, Dec 19, 2017 at 6:03 AM, Hans de Goede <hdegoede@redhat.com

mailto:hdegoede@redhat.com> 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.