From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:53270 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753104AbdHKQJD (ORCPT ); Fri, 11 Aug 2017 12:09:03 -0400 Subject: Re: [RFC 0/2] Add Virtual Box vboxguest and vboxsf guest drivers to the mainline kernel To: Arnd Bergmann Cc: Greg Kroah-Hartman , Alexander Viro , Michael Thayer , "Knut St . Osmundsen" , Larry Finger , Linux Kernel Mailing List , Linux FS-devel Mailing List References: <20170811132324.6216-1-hdegoede@redhat.com> From: Hans de Goede Message-ID: Date: Fri, 11 Aug 2017 18:09:00 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, On 11-08-17 18:02, Arnd Bergmann wrote: > On Fri, Aug 11, 2017 at 3:23 PM, Hans de Goede 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? ;-) 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. >> 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. 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. Regards, hans