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: <251f94d0-7110-aaf1-172b-5120fce2f105@redhat.com>
Date:   Fri, 11 Aug 2017 19:43:36 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Arnd Bergmann <arnd@...db.de>
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

Hi,

On 11-08-17 18:32, Arnd Bergmann wrote:
> On Fri, Aug 11, 2017 at 6:09 PM, Hans de Goede <hdegoede@...hat.com> wrote:
>> On 11-08-17 18:02, Arnd Bergmann wrote:
>>> 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? ;-)
>>
>>
>> Given that there are a lot of users already using the existing interface
>> more the former (the proposed driver implements today) then the latter.
>>
>> But for now they assume that the userspace and kernel module versions
>> are always in sync, so some small fixes might be possible. Some questions
>> from me about unclear behavior of one ioctl command have already let
>> to one small fix. But in general given the long out of tree history
>> of this driver the interface is something which will be hard to change.
> 
> Ok.
> 
>>> 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.
>>
>>
>> I ended up using drivers/misc because that is where the vmware drivers
>> are.
>>
>>> In this case,
>>> would maybe drivers/platform/vbox or drivers/firmware/vbox be better?
>>
>>
>> Definitely not drivers/firmware that feels wrong (the driver talks
>> to a pci device), I personally think adding a new dir under drivers/platform
>> for just the single driver is overkill.
> 
> Actually we have a lot of different places already. I wasn't aware
> of drivers/misc/vmw_vmci/, then we also have drivers/xen, drivers/hv
> drivers/lguest and drivers/virtio for hypervisor specific interfaces, and
> there is drivers/virt/fsl_hypervisor.c.
> 
> In drivers/firmware, we have a couple of similar things, mostly for
> ARM Trustzone based firmware which has a lot in common with a
> hypervisor.
> 
> How about adding it to drivers/virt/ then?

That as actually my first choice, but there is only the 1 driver there
now, so I was thinking that we should move that 1 driver out of there
and get rid of it actually :)

But as said it was my first choice, so maybe it should go there and then
over time we can move all the things you've listed there (assuming anyone
finds the time to do this).

One issues with drivers/virt is no-one is listed for it in MAINTAINERS...

Regards,

Hans