linux-kernel - Re: [RFC 0/2] Add Virtual Box vboxguest and vboxsf guest drivers to the mainline kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a3Cww9ZED5iQFx_6SWe=EVA_k2X2o3mV0aXCqo54gWBSA@mail.gmail.com>
Date:   Fri, 11 Aug 2017 18:02:10 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Michael Thayer <michael.thayer@...cle.com>,
        "Knut St . Osmundsen" <knut.osmundsen@...cle.com>,
        Larry Finger <Larry.Finger@...inger.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC 0/2] Add Virtual Box vboxguest and vboxsf guest drivers to
 the mainline kernel

On Fri, Aug 11, 2017 at 3:23 PM, Hans de Goede <hdegoede@...hat.com> wrote:

> The vboxguest driver introduces a new userspace API + ABI in the form
> of ioctls on a character device. VirtualBox upstream not willing to
> commit to keeping this ABI stable was one of the things which has
> kept this driver driver out of mainline sofar. I've been talking to
> VirtualBox upstream about mainlining the guest drivers and VirtualBox
> upstream has agreed to consider the userspace ABI stable and only
> extend it in a backwards compatible manner.

Can you clarify which ioctl interface they agreed to? Would they
only keep the one that the proposed driver implements today,
or the one we end up with after a full review? ;-)

> As said this is a RFC, the main comments I'm looking for is an answer
> to these 2 questions:
>
> Greg, Arnd would you be willing to merge the vboxguest driver under
> drivers/misc (in principle), assuming I do the remaining cleanup
> and the driver gets a favorable review of course ?
>
> Al, the same question for you for the vboxsf (shared folder) driver?

I think these drivers should be part of the kernel, but I see drivers/misc/
as a last resort location for things that don't fit anywhere else. In this case,
would maybe drivers/platform/vbox or drivers/firmware/vbox be better?

For vboxsf, putting it in fs/vboxsf as your patch does seems fine.

       Arnd