On Fri, Aug 11, 2017 at 6:09 PM, Hans de Goede <hdegoede@xxxxxxxxxx> 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?
Arnd
