On 7/28/19 4:29 AM, Hans-Peter Jansen wrote:
Am Samstag, 27. Juli 2019, 19:10:19 CEST schrieb Larry Finger:
On 7/27/19 9:57 AM, Michal Suchánek wrote:
On Sat, 27 Jul 2019 16:15:13 +0200
Michal Suchánek
wrote: On Sat, 27 Jul 2019 14:57:43 +0200
--snip--
At first glance, Stefan Seyfried's suggestion to merge the host and guest kmp packages into a single unit seems intriguing.
Well, from a power virtualbox user POV, this approach feels wrong. (Sorry, Stefan) After all, kernel modules always contain very delicate code.
Having both, the guest modules as well as the host modules installed everywhere, whether either host or guest functionality is requested, may open a couple of new issues. What happens, if, for some reason, a mix of these modules is loaded? Any chance, they interfere with each other? DoS.. Especially, the vboxfs module is one, that I don't want to see loaded on any host, that I depend on. To the contrary, I already thought of changes to make this module optional.
For the record, I usually add a zypper lock for the guest modules on vbox hosts.
I will explore that locally to see if there are any downsides to this change.
Let's see, how Michals changes to the macros behave.
Given the sheer size of virtualbox.spec today, having separate host and guest kmod specs with a simple automated update script sounds like the most attractive approach to me.
Pete, For Tumbleweed users, vboxvideo has been part of every kernel for several cycles without any complaints from users. As Stephan notes, it refuses to load. Although vboxguest is also a part of the kernel, we still need to build it as the kernel's version has different symbols, thus vboxsf requires the out-of-kernel version. Adding vboxguest and vboxsf to a single kmp package would add only a few MB to the download and total storage required, thus it should not be a system breaker. In fact, Oracle delivers both kinds of modules and everything else in a single RPM. I would argue that the size and complexity of the virtualbox spec argues against having separate kmod specs. The changes required to combine the two kinds of modules is trivial. In addition, checking that section of the spec has resulted in the finding of several if statements that were wrong, thus we are getting some bug fixes "for free". Keeping a single package also preserves the existing update procedures. Michal's changes to the macros may fix the problem, and changing the virtualbox spec may not help, but I am willing to go ahead with changing the spec. We have also been living with some unintended conflicts that should be fixed. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org