[lkml]   [2017]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 0/2] Add Virtual Box vboxguest and vboxsf guest drivers to the mainline kernel
On Fri, Aug 11, 2017 at 6:09 PM, Hans de Goede <> 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.


>> 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

How about adding it to drivers/virt/ then?


 \ /
  Last update: 2017-08-11 18:32    [W:0.090 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site