Hyper-V TODO file

Hyper-V TODO file

[K. Y. Srinivasan]

Greg,

The TODO file for Hyper-V drivers has not been updated in a while and does
not reflect the current state of these drivers:

1) There are no more checkpatch warnings/errors in this code. One of the TODO
work items is "fix remaining checkpatch warnings and errors".

2) With your help, we have fixed all of the issues related to these drivers
conforming to the Linux Device Driver model. One of the TODO work items is 
"audit the vmbus to verify it is working properly with the driver model".

3) Like all other virtualization platforms, the protocol to communicate with
the host is very host specific. The ringbuffer control structures are shared
between the host and the guest and so, the guest is compelled to follow the
mandates of the host. Thus, it is not possible for us to merge the vmbus with
other virtual buses in the system. One of the TODO work items is  "see if the 
vmbus can be merged with the other virtual busses in the kernel".

4) A couple of months ago, we had posted the network driver for community review.
We have submitted patches (and these have been applied) to address the review
comments. One of the TODO work items is "audit the network driver"

5) Recently, we have merged the IDE and scsi drivers into a single driver that
can handle both IDE and SCSI devices. These patches have been already checked in.
As part of this effort, we have addressed all of the community comments on the
combined storage driver. The TODO file currently has two work items on this
issue: "audit the block driver" and "audit the scsi driver".

Greg, as I have been pestering you for some time now, we are very interested in
exiting staging and we are willing to dedicate the necessary development 
resources to address whatever issues that may still be pending. So, your help
in identifying what needs to be done will be greatly appreciated. To that end,
I think it will be useful to update the TODO file to reflect the current state of
the drivers. Let us know how we should proceed here. 

Regards,

K. Y

Re: Hyper-V TODO file

[Peter Foley]

On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> Greg, as I have been pestering you for some time now, we are very interested in
> exiting staging and we are willing to dedicate the necessary development 
> resources to address whatever issues that may still be pending. So, your help
> in identifying what needs to be done will be greatly appreciated. To that end,
> I think it will be useful to update the TODO file to reflect the current state of
> the drivers. Let us know how we should proceed here. 
 
An issue I've come across in the hyper-v drivers is the forced modular 
build. You might want to see if the "depends on m" is still needed.

Thanks,

Peter Foley

Re: Hyper-V TODO file

[Greg KH]

On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> 
> Greg,
> 
> The TODO file for Hyper-V drivers has not been updated in a while and does
> not reflect the current state of these drivers:
> 
> 1) There are no more checkpatch warnings/errors in this code. One of the TODO
> work items is "fix remaining checkpatch warnings and errors".

Great, you can delete it.

> 2) With your help, we have fixed all of the issues related to these drivers
> conforming to the Linux Device Driver model. One of the TODO work items is 
> "audit the vmbus to verify it is working properly with the driver model".

I have a few comments about this, I'll respond in another email.

> 3) Like all other virtualization platforms, the protocol to communicate with
> the host is very host specific. The ringbuffer control structures are shared
> between the host and the guest and so, the guest is compelled to follow the
> mandates of the host. Thus, it is not possible for us to merge the vmbus with
> other virtual buses in the system. One of the TODO work items is  "see if the 
> vmbus can be merged with the other virtual busses in the kernel".

Sure, you can delete it.

> 4) A couple of months ago, we had posted the network driver for community review.
> We have submitted patches (and these have been applied) to address the review
> comments. One of the TODO work items is "audit the network driver"

Leave that until the network subsystem authors agree that this is all
taken care of by merging the driver into their subsystem.

> 5) Recently, we have merged the IDE and scsi drivers into a single driver that
> can handle both IDE and SCSI devices. These patches have been already checked in.
> As part of this effort, we have addressed all of the community comments on the
> combined storage driver. The TODO file currently has two work items on this
> issue: "audit the block driver" and "audit the scsi driver".

Same as above for the network driver, but you can leave just one entry
now.

I can't apply patches right now due to the kernel.org infrastructure
reworking, so you will have to wait a few days for me to apply your
previous ones, but feel free to send a patch cleaning up the TODO file
now.

thanks,

greg k-h

Re: Hyper-V TODO file

[Greg KH]

On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > 2) With your help, we have fixed all of the issues related to these drivers
> > conforming to the Linux Device Driver model. One of the TODO work items is 
> > "audit the vmbus to verify it is working properly with the driver model".
> 
> I have a few comments about this, I'll respond in another email.

Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
one:

- rename the vmbus_child_* functions to vmbus_* as there's no need to
  think of "children" here.

- vmbus_onoffer comment is incorrect.  You handle offers from lots of
  other types.  Or if not, am I reading the code incorrectly?

- the static hv_cb_utils array needs to go away.  In the hv_utils.c
  util_probe() call, properly register the channel callback, and the
  same goes for the util_remove() call, unregister things there.
  Note, you can use the driver_data field to determine exactly which
  callback needs to be registered to make things easy.  Something like
  the following (pseudo code only):

static const struct hv_vmbus_device_id id_table[] = {
	/* Shutdown guid */
	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
	  .driver_data = &shutdown_onchannelcallback },
	....
};

util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
 [ Yes, you will have to change the probe callback signature, but that's fine. ]
{
	void *fn(void *context);
	u8 *buffer;

	fn = id->driver_data;
	buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);

	/* Hook up callback and buffer with a call to the proper vmbus
	 * function
	 */
	 ...
}

util_remove()
{
	/* undo what you did in util_probe(), unhooking the callback and
	 * freeing the data */
}


Does that make any sense?

thanks,

greg k-h

Re: Hyper-V TODO file

[Greg KH]

On Wed, Aug 31, 2011 at 07:11:39PM -0400, Peter Foley wrote:
> On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> > Greg, as I have been pestering you for some time now, we are very interested in
> > exiting staging and we are willing to dedicate the necessary development 
> > resources to address whatever issues that may still be pending. So, your help
> > in identifying what needs to be done will be greatly appreciated. To that end,
> > I think it will be useful to update the TODO file to reflect the current state of
> > the drivers. Let us know how we should proceed here. 
>  
> An issue I've come across in the hyper-v drivers is the forced modular 
> build. You might want to see if the "depends on m" is still needed.

Ah, good point, KY, can you try this out and see if that can be changed?
If not, something is wrong and that needs to get fixed.

thanks,

greg k-h

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:28 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> >
> > Greg,
> >
> > The TODO file for Hyper-V drivers has not been updated in a while and does
> > not reflect the current state of these drivers:
> >
> > 1) There are no more checkpatch warnings/errors in this code. One of the
> TODO
> > work items is "fix remaining checkpatch warnings and errors".
> 
> Great, you can delete it.

Will do.
> 
> > 2) With your help, we have fixed all of the issues related to these drivers
> > conforming to the Linux Device Driver model. One of the TODO work items is
> > "audit the vmbus to verify it is working properly with the driver model".
> 
> I have a few comments about this, I'll respond in another email.
> 
> > 3) Like all other virtualization platforms, the protocol to communicate with
> > the host is very host specific. The ringbuffer control structures are shared
> > between the host and the guest and so, the guest is compelled to follow the
> > mandates of the host. Thus, it is not possible for us to merge the vmbus with
> > other virtual buses in the system. One of the TODO work items is  "see if the
> > vmbus can be merged with the other virtual busses in the kernel".
> 
> Sure, you can delete it.
> 
Will do.
> > 4) A couple of months ago, we had posted the network driver for community
> review.
> > We have submitted patches (and these have been applied) to address the
> review
> > comments. One of the TODO work items is "audit the network driver"
> 
> Leave that until the network subsystem authors agree that this is all
> taken care of by merging the driver into their subsystem.
> 
Ok; will do.

> > 5) Recently, we have merged the IDE and scsi drivers into a single driver that
> > can handle both IDE and SCSI devices. These patches have been already
> checked in.
> > As part of this effort, we have addressed all of the community comments on
> the
> > combined storage driver. The TODO file currently has two work items on this
> > issue: "audit the block driver" and "audit the scsi driver".
> 
> Same as above for the network driver, but you can leave just one entry
> now.

Ok; will do.
> 
> I can't apply patches right now due to the kernel.org infrastructure
> reworking, so you will have to wait a few days for me to apply your
> previous ones, but feel free to send a patch cleaning up the TODO file
> now.

Thanks Greg. I will get the patches out soon.

Regards,

K. Y

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:31 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > 2) With your help, we have fixed all of the issues related to these drivers
> > > conforming to the Linux Device Driver model. One of the TODO work items is
> > > "audit the vmbus to verify it is working properly with the driver model".
> >
> > I have a few comments about this, I'll respond in another email.
> 
> Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> one:
> 
> - rename the vmbus_child_* functions to vmbus_* as there's no need to
>   think of "children" here.

Ok; will do.
> 
> - vmbus_onoffer comment is incorrect.  You handle offers from lots of
>   other types.  Or if not, am I reading the code incorrectly?

You are right; I will clean this up.

> 
> - the static hv_cb_utils array needs to go away.  In the hv_utils.c
>   util_probe() call, properly register the channel callback, and the
>   same goes for the util_remove() call, unregister things there.
>   Note, you can use the driver_data field to determine exactly which
>   callback needs to be registered to make things easy.  Something like
>   the following (pseudo code only):
> 
> static const struct hv_vmbus_device_id id_table[] = {
> 	/* Shutdown guid */
> 	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
> 		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
> 	  .driver_data = &shutdown_onchannelcallback },
> 	....
> };
> 
> util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
>  [ Yes, you will have to change the probe callback signature, but that's fine. ]
> {
> 	void *fn(void *context);
> 	u8 *buffer;
> 
> 	fn = id->driver_data;
> 	buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
> 
> 	/* Hook up callback and buffer with a call to the proper vmbus
> 	 * function
> 	 */
> 	 ...
> }
> 
> util_remove()
> {
> 	/* undo what you did in util_probe(), unhooking the callback and
> 	 * freeing the data */
> }
> 
> 
> Does that make any sense?

Yes; I will get these patches to you soon. I see how the data ptr can be used;
I will buy you the beer the next time we meet.

Regards,

K. Y
> 
> thanks,
> 
> greg k-h

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:31 PM
> To: Peter Foley
> Cc: KY Srinivasan; gregkh@suse.de; Linux Kernel Mailing List;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Wed, Aug 31, 2011 at 07:11:39PM -0400, Peter Foley wrote:
> > On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> > > Greg, as I have been pestering you for some time now, we are very
> interested in
> > > exiting staging and we are willing to dedicate the necessary development
> > > resources to address whatever issues that may still be pending. So, your help
> > > in identifying what needs to be done will be greatly appreciated. To that end,
> > > I think it will be useful to update the TODO file to reflect the current state of
> > > the drivers. Let us know how we should proceed here.
> >
> > An issue I've come across in the hyper-v drivers is the forced modular
> > build. You might want to see if the "depends on m" is still needed.
> 
> Ah, good point, KY, can you try this out and see if that can be changed?
> If not, something is wrong and that needs to get fixed.

I will check it and let you know. If there are issues, I fill fix them

Regards,

K. Y

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:31 PM
> To: Peter Foley
> Cc: KY Srinivasan; gregkh@suse.de; Linux Kernel Mailing List;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Wed, Aug 31, 2011 at 07:11:39PM -0400, Peter Foley wrote:
> > On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> > > Greg, as I have been pestering you for some time now, we are very
> interested in
> > > exiting staging and we are willing to dedicate the necessary development
> > > resources to address whatever issues that may still be pending. So, your help
> > > in identifying what needs to be done will be greatly appreciated. To that end,
> > > I think it will be useful to update the TODO file to reflect the current state of
> > > the drivers. Let us know how we should proceed here.
> >
> > An issue I've come across in the hyper-v drivers is the forced modular
> > build. You might want to see if the "depends on m" is still needed.
> 
> Ah, good point, KY, can you try this out and see if that can be changed?
> If not, something is wrong and that needs to get fixed.

Just verified that we can build into the kernel (not as modules) all hyper-V
drivers except hv_storvsc. hv_storvsc depends upon functionality that in my build 
is being built as modules (SCSI etc.) and this is the reason why I could not build
hv_storvsc as part of the kernel.

Greg, do you want me to submit a patch to Kconfig, getting rid of the module
dependency (for hyperv-v drivers).

Regards,

K. Y

Re: Hyper-V TODO file

[Greg KH]

On Fri, Sep 02, 2011 at 03:17:19PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Thursday, September 01, 2011 4:31 PM
> > To: Peter Foley
> > Cc: KY Srinivasan; gregkh@suse.de; Linux Kernel Mailing List;
> > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > Subject: Re: Hyper-V TODO file
> > 
> > On Wed, Aug 31, 2011 at 07:11:39PM -0400, Peter Foley wrote:
> > > On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> > > > Greg, as I have been pestering you for some time now, we are very
> > interested in
> > > > exiting staging and we are willing to dedicate the necessary development
> > > > resources to address whatever issues that may still be pending. So, your help
> > > > in identifying what needs to be done will be greatly appreciated. To that end,
> > > > I think it will be useful to update the TODO file to reflect the current state of
> > > > the drivers. Let us know how we should proceed here.
> > >
> > > An issue I've come across in the hyper-v drivers is the forced modular
> > > build. You might want to see if the "depends on m" is still needed.
> > 
> > Ah, good point, KY, can you try this out and see if that can be changed?
> > If not, something is wrong and that needs to get fixed.
> 
> Just verified that we can build into the kernel (not as modules) all hyper-V
> drivers except hv_storvsc. hv_storvsc depends upon functionality that in my build 
> is being built as modules (SCSI etc.) and this is the reason why I could not build
> hv_storvsc as part of the kernel.

So 'make allyesconfig' with the module dependancy turned off doesn't
break the build?  If so, great.

> Greg, do you want me to submit a patch to Kconfig, getting rid of the module
> dependency (for hyperv-v drivers).

Yes please.

thanks,

greg k-h

Re: Hyper-V TODO file

[Greg KH]

On Thu, Sep 01, 2011 at 01:30:31PM -0700, Greg KH wrote:
> On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > 2) With your help, we have fixed all of the issues related to these drivers
> > > conforming to the Linux Device Driver model. One of the TODO work items is 
> > > "audit the vmbus to verify it is working properly with the driver model".
> > 
> > I have a few comments about this, I'll respond in another email.
> 
> Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> one:

Oh, here's another issue I forgot about.  You can get rid of the 'ext'
field of the hv_device structure and use the proper function in the
driver core for this type of thing, just wrap it up in your own function
to make it "sane" looking, like USB and PCI does with their
usb_get_intfdata(), usb_set_intfdata(), pci_get_drvdata(), and
pci_set_drvdata() functions.

thanks,

greg k-h

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:31 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > 2) With your help, we have fixed all of the issues related to these drivers
> > > conforming to the Linux Device Driver model. One of the TODO work items is
> > > "audit the vmbus to verify it is working properly with the driver model".
> >
> > I have a few comments about this, I'll respond in another email.
> 
> Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> one:
> 
> - rename the vmbus_child_* functions to vmbus_* as there's no need to
>   think of "children" here.
> 
> - vmbus_onoffer comment is incorrect.  You handle offers from lots of
>   other types.  Or if not, am I reading the code incorrectly?
> 
> - the static hv_cb_utils array needs to go away.  In the hv_utils.c
>   util_probe() call, properly register the channel callback, and the
>   same goes for the util_remove() call, unregister things there.
>   Note, you can use the driver_data field to determine exactly which
>   callback needs to be registered to make things easy.  Something like
>   the following (pseudo code only):
> 
> static const struct hv_vmbus_device_id id_table[] = {
> 	/* Shutdown guid */
> 	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
> 		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
> 	  .driver_data = &shutdown_onchannelcallback },
> 	....
> };
> 
> util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
>  [ Yes, you will have to change the probe callback signature, but that's fine. ]

Greg, I think if I understand you correctly, the id parameter to the probe function
would be pointing to relevant entry in the hv_vmbus_device_id array. Since the driver
can handle multiple ids (guids), we need to either in the driver specific probe function or
in the bus specific probe function,  figure out which of the many devices the driver
supports is being probed. I have couple of implementation options and would appreciate 
your preference:

1) Do the guid parsing at the vmbus level parsing function. If I go this route, the driver specific probe
function would get an extra parameter as you have described in pseudo code.

2) Do the guid parsing in the util probe function. In this case, we don't need to change the signature for
the probe function as all the id information is available in the (util) driver. 

I personally would prefer the second approach since it does not affect other drivers (no need to change
the signature for the probe function). Let me know how you want me to proceed here.

Regards,

K. Y

Re: Hyper-V TODO file

[Greg KH]

On Fri, Sep 02, 2011 at 07:47:12PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Thursday, September 01, 2011 4:31 PM
> > To: KY Srinivasan
> > Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > Subject: Re: Hyper-V TODO file
> > 
> > On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > > 2) With your help, we have fixed all of the issues related to these drivers
> > > > conforming to the Linux Device Driver model. One of the TODO work items is
> > > > "audit the vmbus to verify it is working properly with the driver model".
> > >
> > > I have a few comments about this, I'll respond in another email.
> > 
> > Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> > one:
> > 
> > - rename the vmbus_child_* functions to vmbus_* as there's no need to
> >   think of "children" here.
> > 
> > - vmbus_onoffer comment is incorrect.  You handle offers from lots of
> >   other types.  Or if not, am I reading the code incorrectly?
> > 
> > - the static hv_cb_utils array needs to go away.  In the hv_utils.c
> >   util_probe() call, properly register the channel callback, and the
> >   same goes for the util_remove() call, unregister things there.
> >   Note, you can use the driver_data field to determine exactly which
> >   callback needs to be registered to make things easy.  Something like
> >   the following (pseudo code only):
> > 
> > static const struct hv_vmbus_device_id id_table[] = {
> > 	/* Shutdown guid */
> > 	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
> > 		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
> > 	  .driver_data = &shutdown_onchannelcallback },
> > 	....
> > };
> > 
> > util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
> >  [ Yes, you will have to change the probe callback signature, but that's fine. ]
> 
> Greg, I think if I understand you correctly, the id parameter to the probe function
> would be pointing to relevant entry in the hv_vmbus_device_id array.

Yes, just like it does for USB, PCI, etc.

> Since the driver can handle multiple ids (guids), we need to either in
> the driver specific probe function or in the bus specific probe
> function,  figure out which of the many devices the driver supports is
> being probed. I have couple of implementation options and would
> appreciate your preference:
> 
> 1) Do the guid parsing at the vmbus level parsing function. If I go
> this route, the driver specific probe function would get an extra
> parameter as you have described in pseudo code.

Yes, that's the proper way to do this, as your match function already
found the proper id structure, so you have the pointer, just pass it to
the probe function callback.

> 2) Do the guid parsing in the util probe function. In this case, we
> don't need to change the signature for the probe function as all the
> id information is available in the (util) driver. 

Yes, but you end up doing the matching all over again in the util
driver, which isn't nice and ripe for duplication and bugs.

> I personally would prefer the second approach since it does not affect
> other drivers (no need to change the signature for the probe
> function). Let me know how you want me to proceed here.

As you only have 3 probe functions, it's not a big deal to change them
all :)

thanks,

greg k-h

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Friday, September 02, 2011 3:58 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Fri, Sep 02, 2011 at 07:47:12PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg@kroah.com]
> > > Sent: Thursday, September 01, 2011 4:31 PM
> > > To: KY Srinivasan
> > > Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> > > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > > Subject: Re: Hyper-V TODO file
> > >
> > > On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > > > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > > > 2) With your help, we have fixed all of the issues related to these drivers
> > > > > conforming to the Linux Device Driver model. One of the TODO work
> items is
> > > > > "audit the vmbus to verify it is working properly with the driver model".
> > > >
> > > > I have a few comments about this, I'll respond in another email.
> > >
> > > Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> > > one:
> > >
> > > - rename the vmbus_child_* functions to vmbus_* as there's no need to
> > >   think of "children" here.
> > >
> > > - vmbus_onoffer comment is incorrect.  You handle offers from lots of
> > >   other types.  Or if not, am I reading the code incorrectly?
> > >
> > > - the static hv_cb_utils array needs to go away.  In the hv_utils.c
> > >   util_probe() call, properly register the channel callback, and the
> > >   same goes for the util_remove() call, unregister things there.
> > >   Note, you can use the driver_data field to determine exactly which
> > >   callback needs to be registered to make things easy.  Something like
> > >   the following (pseudo code only):
> > >
> > > static const struct hv_vmbus_device_id id_table[] = {
> > > 	/* Shutdown guid */
> > > 	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
> > > 		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
> > > 	  .driver_data = &shutdown_onchannelcallback },
> > > 	....
> > > };
> > >
> > > util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
> > >  [ Yes, you will have to change the probe callback signature, but that's fine. ]
> >
> > Greg, I think if I understand you correctly, the id parameter to the probe
> function
> > would be pointing to relevant entry in the hv_vmbus_device_id array.
> 
> Yes, just like it does for USB, PCI, etc.
> 
> > Since the driver can handle multiple ids (guids), we need to either in
> > the driver specific probe function or in the bus specific probe
> > function,  figure out which of the many devices the driver supports is
> > being probed. I have couple of implementation options and would
> > appreciate your preference:
> >
> > 1) Do the guid parsing at the vmbus level parsing function. If I go
> > this route, the driver specific probe function would get an extra
> > parameter as you have described in pseudo code.
> 
> Yes, that's the proper way to do this, as your match function already
> found the proper id structure, so you have the pointer, just pass it to
> the probe function callback.
> 
> > 2) Do the guid parsing in the util probe function. In this case, we
> > don't need to change the signature for the probe function as all the
> > id information is available in the (util) driver.
> 
> Yes, but you end up doing the matching all over again in the util
> driver, which isn't nice and ripe for duplication and bugs.
> 
> > I personally would prefer the second approach since it does not affect
> > other drivers (no need to change the signature for the probe
> > function). Let me know how you want me to proceed here.
> 
> As you only have 3 probe functions, it's not a big deal to change them
> all :)

Ok; will do. I am glad I checked with you!

Regards,

K. Y

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Tuesday, October 04, 2011 1:04 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Tue, Oct 04, 2011 at 01:59:56PM +0000, KY Srinivasan wrote:
> > Greg, sometime back you checked in the changes to the TODO file reflecting
> > that there are no outstanding vmbus related issues. What is the process now
> > for getting the vmbus (and util) drivers out of staging. Let me know if there is
> > something I can do to help this along.  As you know, we had posted the
> network
> > driver for public review a while ago (several months ago) and we have
> addressed
> > all the review comments we got. Any guidance on what we should do next
> would be
> > greatly appreciated.
> 
> At this point in time, just ask me, and I will move the files.
> 
> So, to confirm, you want to have the following files moved to
> drivers/hv/:
> 	drivers/staging/hv/Kconfig (part of this file)
> 	drivers/staging/hv/Makefile (part of this file)
> 	drivers/staging/hv/vmbus_drv.c
> 	drivers/staging/hv/hv.c
> 	drivers/staging/hv/connection.c
> 	drivers/staging/hv/channel.c
> 	drivers/staging/hv/channel_mgmt.c
> 	drivers/staging/hv/ring_buffer.c
> 	drivers/staging/hv/hv_util.c
> 	drivers/staging/hv/hv_kmp.c
This is hv_kvp.c
> 	drivers/staging/hv/hv_kvp.h
> 	drivers/staging/hv/hyperv_vmbus.h
> 

Yes; this would be the list of files to be moved to drivers/hv/

> The following file moved to include/linux/:
> 	drivers/staging/hv/hyperv.h
> (I think there is stuff in there that can go into hyperv_vmbus.h as it's
> not needed in the "global" directory, but I can do that movement.)
> 

Correct.
> The following file moved to tools/hv/:
> 	drivers/staging/hv/tools/*
> 
> And the following files modified to tie drivers/hv/ into the build service:
> 	drivers/Makefile
> 	drivers/Kconfig
> 
> Is all of that correct?
> 

Yes; the list you have is correct. Thanks a lot for doing this.

Regards,

K. Y

Re: Hyper-V TODO file

[Greg KH]

On Tue, Oct 04, 2011 at 01:59:56PM +0000, KY Srinivasan wrote:
> Greg, sometime back you checked in the changes to the TODO file reflecting
> that there are no outstanding vmbus related issues. What is the process now
> for getting the vmbus (and util) drivers out of staging. Let me know if there is 
> something I can do to help this along.  As you know, we had posted the network 
> driver for public review a while ago (several months ago) and we have addressed 
> all the review comments we got. Any guidance on what we should do next would be
> greatly appreciated.

At this point in time, just ask me, and I will move the files.

So, to confirm, you want to have the following files moved to
drivers/hv/:
	drivers/staging/hv/Kconfig (part of this file)
	drivers/staging/hv/Makefile (part of this file)
	drivers/staging/hv/vmbus_drv.c
	drivers/staging/hv/hv.c
	drivers/staging/hv/connection.c
	drivers/staging/hv/channel.c
	drivers/staging/hv/channel_mgmt.c
	drivers/staging/hv/ring_buffer.c
	drivers/staging/hv/hv_util.c
	drivers/staging/hv/hv_kmp.c
	drivers/staging/hv/hv_kvp.h
	drivers/staging/hv/hyperv_vmbus.h

The following file moved to include/linux/:
	drivers/staging/hv/hyperv.h
(I think there is stuff in there that can go into hyperv_vmbus.h as it's
not needed in the "global" directory, but I can do that movement.)

The following file moved to tools/hv/:
	drivers/staging/hv/tools/*

And the following files modified to tie drivers/hv/ into the build service:
	drivers/Makefile
	drivers/Kconfig

Is all of that correct?

thanks,

greg k-h

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Thursday, September 22, 2011 1:36 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 22, 2011 at 05:20:59PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@suse.de]
> > > Sent: Thursday, September 22, 2011 1:05 PM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org
> > > Subject: Re: Hyper-V TODO file
> > >
> > > On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> > > >
> > > > Greg,
> > > >
> > > > With your last checkin of the patches for Hyper-V, I have addressed all of
> > > > the issues you had raised as part of the vmbus audit. Should I send you a
> > > > patch to update the TODO file to reflect this. Let me know.
> > >
> > > Yes, please send patches.
> >
> > Thanks Greg. In addition to the patch to update the TODO file, do you want me
> to
> > send you patches for moving the vmbus and util driver out of staging as well.
> 
> No, I'll do that if we agree that it is ready to do so.

Greg, sometime back you checked in the changes to the TODO file reflecting
that there are no outstanding vmbus related issues. What is the process now
for getting the vmbus (and util) drivers out of staging. Let me know if there is 
something I can do to help this along.  As you know, we had posted the network 
driver for public review a while ago (several months ago) and we have addressed 
all the review comments we got. Any guidance on what we should do next would be
greatly appreciated.

Regards,

K. Y

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Thursday, September 22, 2011 1:36 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 22, 2011 at 05:20:59PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@suse.de]
> > > Sent: Thursday, September 22, 2011 1:05 PM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org
> > > Subject: Re: Hyper-V TODO file
> > >
> > > On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> > > >
> > > > Greg,
> > > >
> > > > With your last checkin of the patches for Hyper-V, I have addressed all of
> > > > the issues you had raised as part of the vmbus audit. Should I send you a
> > > > patch to update the TODO file to reflect this. Let me know.
> > >
> > > Yes, please send patches.
> >
> > Thanks Greg. In addition to the patch to update the TODO file, do you want me
> to
> > send you patches for moving the vmbus and util driver out of staging as well.
> 
> No, I'll do that if we agree that it is ready to do so.

Fair enough! When you said earlier  " Yes, please send patches", I naturally assumed that you
meant more than a single patch required to update the TODO file. I must admit that  there was also
a good measure of wishful thinking on my part as well! 

Regards,

K. Y

Re: Hyper-V TODO file

[Greg KH]

On Thu, Sep 22, 2011 at 05:20:59PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@suse.de]
> > Sent: Thursday, September 22, 2011 1:05 PM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > virtualization@lists.osdl.org
> > Subject: Re: Hyper-V TODO file
> > 
> > On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> > >
> > > Greg,
> > >
> > > With your last checkin of the patches for Hyper-V, I have addressed all of
> > > the issues you had raised as part of the vmbus audit. Should I send you a
> > > patch to update the TODO file to reflect this. Let me know.
> > 
> > Yes, please send patches.
> 
> Thanks Greg. In addition to the patch to update the TODO file, do you want me to
> send you patches for moving the vmbus and util driver out of staging as well.

No, I'll do that if we agree that it is ready to do so.

thanks,

greg k-h

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Thursday, September 22, 2011 1:05 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> >
> > Greg,
> >
> > With your last checkin of the patches for Hyper-V, I have addressed all of
> > the issues you had raised as part of the vmbus audit. Should I send you a
> > patch to update the TODO file to reflect this. Let me know.
> 
> Yes, please send patches.

Thanks Greg. In addition to the patch to update the TODO file, do you want me to
send you patches for moving the vmbus and util driver out of staging as well.

Regards,

K. Y

Re: Hyper-V TODO file

[Greg KH]

On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> 
> Greg,
> 
> With your last checkin of the patches for Hyper-V, I have addressed all of 
> the issues you had raised as part of the vmbus audit. Should I send you a 
> patch to update the TODO file to reflect this. Let me know.

Yes, please send patches.

Hyper-V TODO file

[K. Y. Srinivasan]

Greg,

With your last checkin of the patches for Hyper-V, I have addressed all of 
the issues you had raised as part of the vmbus audit. Should I send you a 
patch to update the TODO file to reflect this. Let me know.


Regards,

K. Y

Re: Hyper-V TODO file

[Joe Perches]

On Thu, 2011-09-22 at 09:17 -0700, K. Y. Srinivasan wrote:
> With your last checkin of the patches for Hyper-V, I have addressed all of 
> the issues you had raised as part of the vmbus audit. Should I send you a 
> patch to update the TODO file to reflect this. Let me know.

Is there really anything left to do but send
the patch that moves hv out of staging?

Re: Hyper-V TODO file

[Joe Perches]

On Thu, 2011-09-22 at 09:17 -0700, K. Y. Srinivasan wrote:
> With your last checkin of the patches for Hyper-V, I have addressed all of 
> the issues you had raised as part of the vmbus audit. Should I send you a 
> patch to update the TODO file to reflect this. Let me know.

Is there really anything left to do but send
the patch that moves hv out of staging?