Hi,
On 14-07-17 14:57, Josh Boyer wrote:
On Sat, Jul 8, 2017 at 9:36 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Hi,
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@xxxxxxxxx> wrote:
We want to make the default installation do the right thing, as far
as
possible, on any system, without any explicit configuration or
admin steps.
In this case it's possible: if a virtualization "channel" is
configured,
we should assume that the user wants the service. This means that
the
"guest additions" rpms should be a) installed by default, b)
enabled
when installed, c) work ootb when running in the right
virtualization
and silently do nothing otherwise.
Essentially, I want to take the same image and boot it in
virtualbox,
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
from
the "Guiest Additions" iso image, unless great caution is employed
and
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 [1] we got vboxservice.service which have
ConditionVirtualization=|oracle
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
quite small.
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
main focus.
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.
Regards,
Hans
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
