Hyper-V vmbus driver

Greg KH greg at kroah.com
Sat Apr 23 15:20:55 UTC 2011


On Mon, Apr 11, 2011 at 12:07:08PM -0700, Greg KH wrote:
> > With that patch-set, I think I have addressed all architectural issues that I
> > am aware of.
> > 
> > I was wondering if you would have the time to let me know what else would have
> > to be addressed
> > 
> > in the vmbus driver, before it could be considered ready for exiting staging.
> > As always your help is
> > 
> > greatly appreciated.
> 
> Anyway, yes, I discussed this with Hank last week at the LF Collab
> summit.  I'll look at the vmbus code later this week when I catch up on
> all of my other work (stable, usb, tty, staging, etc.) that has piled up
> during my 2 week absence, and get back to you with what I feel is still
> needed to be done, if anything.

Due to other external issues, my patch backlog is still not gotten
through yet, sorry.  Sometimes "real life" intrudes on the best of
plans.

I'll get to this when I get through the rest of your hv patches, and the
other patches pending that I have in my queues.

But, I would recommend you going through and looking at the code and
verifying that you feel the bus code is "ready".  At a very quick
glance, you should not have individual drivers have to set their 'struct
device' pointers directly, that is something that the bus does, not the
driver.  The driver core will call your bus and your bus will then do
the matching and call the probe function of the driver if needed.

See the PCI driver structure for an example of this if you are curious.
It should also allow you to get rid of that unneeded *priv pointer in
the struct hv_driver.  You should be able to set that structure
constant, like all other busses.  Right now you can not which shows a
design issue.

So, take a look at that and let me know what you think.

thanks,

greg k-h



More information about the devel mailing list