On 14-07-17 14:57, Josh Boyer wrote:
On Sat, Jul 8, 2017 at 9:36 AM, Hans de Goede
> On 07-07-17 16:43, Sérgio Basto wrote:
>> On Fri, 2017-07-07 at 08:14 -0400, Nico Kadel-Garcia wrote:
>>> On Thu, Jul 6, 2017 at 2:57 PM, Zbigniew Jędrzejewski-Szmek
>>> <zbyszek(a)in.waw.pl> wrote:
>>>> We want to make the default installation do the right thing, as far
>>>> possible, on any system, without any explicit configuration or
>>>> admin steps.
>>>> In this case it's possible: if a virtualization "channel"
>>>> we should assume that the user wants the service. This means that
>>>> "guest additions" rpms should be a) installed by default, b)
>>>> when installed, c) work ootb when running in the right
>>>> and silently do nothing otherwise.
>>>> Essentially, I want to take the same image and boot it in
>>>> kvm, on bare metal, and in a container, and have things just work.
>>> Good luck with that. Since the Virtualbox guest additions are *not*
>>> RPM enabled from their installation CD images, RPM is likely to
>>> interfere with working, more recent installations of VBox drivers
>>> the "Guiest Additions" iso image, unless great caution is employed
>>> unless someone can convince them to be completely consistent in
>>> installation tools, or to gracefully allow older and newer verson on
>>> the same host.
>> yes, we need install VirtualBox-guest-additions , which means
>> VirtualBox will be one Fedora Package and BTW I hope that Fedora use
>> RPMFusion package or based on that, I have many work there.
>> And there  we got vboxservice.service which have
> No worries I do plan to use your package as a starting point and
> I will coordinate with you. For now I'm focussed on cleaning up the
> kernel module stuff though.
Do you expect this to be complete and upstream in time for F27?
I don't expect all the kernel-bits to be in the upstream kernel
F27 will use. I do hope to have them in -next (in staging likely)
so we would only have to carry patches for this for a short while.
Note the vboxvideo driver just got merged for 4.13-rc#, so that is
1 done, 2 to go: vboxguest and vboxsf, with the latter one being
vboxguest is 100,000 lines of code which I plan to cut down to
aprox 10,000 as the rest is a portable runtime to allow the same
driver code to run on 4 different OS-es. This currently is my
While the upstream work is on-going, are you proposing to add the
drivers to the kernel package via a patch?
Yes adding (some of) the drivers to the kernel package via a patch
is the plan, I plan to coordinate this with the kennel team when
I do the first upstream submission of the vboxguest driver, as then
I can actually show that this is just a well contained small
(10k lines) driver and not the monster it is now.