Re: [vmw_vmci 11/11] Apply the header code to make VMCI build

----- Original Message -----

From: "Greg KH" <gregkh@linuxfoundation.org>
To: "Andrew Stiegmann" <redacted>
Cc: "Sam Ravnborg" <redacted>, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
pv-drivers@vmware.com, vm-crosstalk@vmware.com, cschamp@vmware.com
Sent: Friday, July 27, 2012 11:16:39 AM
Subject: Re: [vmw_vmci 11/11] Apply the header code to make VMCI build

On Fri, Jul 27, 2012 at 10:20:43AM -0700, Andrew Stiegmann wrote:

quoted

quoted

The kernel style is to use lower_case for everything.
So this would become:

    vmci_device_get()

This is obviously a very general comment and applies everywhere.

I wish I could lower case these symbols but VMCI has already
existed
outside the mainline Linux tree for some time now and changing
these
exported symbols would mean that other drivers that depend on VMCI
(vSock, vmhgfs) would need to change as well.   One thought that
did
come to mind was exporting both VMCI_Device_Get and vmci_device_get
but that would likely just confuse people.  So in short I have made
function names lower case where possible, but exported symbols
could
not be changed.

Not true at all.  You want those drivers to be merged as well, right?
So they will need to have their functions changed, and their code as
well.

As previously mentioned VMware is working on upstreaming our vSock driver (one of a few drivers that uses vmw_vmci).  However there are no plans to upstream the other drivers that depend on vmw_vmci.  Because of this these symbols can not change.

Just wait until we get to the "change your functionality around"
requests, those will require those drivers to change.  Right now we
are
at the "silly and obvious things you did wrong" stage of the review
process :)

So please fix these, and also, post these drivers as well, so we can
see
how they interact with the core code.

Actually, if you are going to need lots of refactoring for these
drivers, and the core, I would recommend putting this all in the
staging
tree, to allow that to happen over time.  That would ensure that your
users keep having working systems, and let you modify the interfaces
better and easier, than having to keep it all out-of-tree.

What do you think?

We will discuss this internally and let you know.
 

greg k-h