> -----Original Message----- > From: Greg KH [mailto:greg@xxxxxxxxx] > Sent: Wednesday, May 04, 2011 12:32 PM > To: KY Srinivasan > Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx > Subject: Re: various vmbus review comments > > On Wed, May 04, 2011 at 04:20:11PM +0000, KY Srinivasan wrote: > > > > > > > -----Original Message----- > > > From: Greg KH [mailto:greg@xxxxxxxxx] > > > Sent: Tuesday, May 03, 2011 4:47 PM > > > To: KY Srinivasan > > > Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx > > > Subject: various vmbus review comments > > > > > > I just took a quick look at the vmbus code, and have the following > > > > I have currently consolidated all the header files as follows: > > > > 1) hyperv.h - this will have all the vmbus related definitions > > needed to build drivers that attach to the bus (as you have suggested). > > Great. > > > 2) hyperv_storage.h - this has all the definitions needed to build storage > > drivers for Hyper-V. Storage drivers will include hyperv.h and > > hyperv_storage.h. > > > > 3) hyperv_net.h - this has all the definitions needed to build the network > > driver for Hyper-V. The netvsc driver will include hyperv.h and hyperv_net.h. > > > > 4) hyperv_utils.h - this has all the definitions needed to build the util driver. > > The util driver would include hyperv.h and hyperv_utils.h. > > No for all 3 of these. Why would a simple driver need a .h file at all? > Just include the structures within the .c file, making it nice and > self-contained. There's no need to clutter things up, and individual > driver .h files should _never_ be in include/linux. Agreed - we don't need to clutter up include/linux directory with individual driver.h files. However, including all the definitions in the .c file would also be ugly. For instance there are multiple *.c files for the storage drivers and we don't want to replicate the contents of hyperv_storage.h in each of these .c files. The same is true for the netvsc driver - there are multiple .c files where we would need to replicate the contents of hyperv_net.h. How about I keep these driver specific header files; but these could be local to the directory where these drivers land. > > > > > - the instances of hv_driver structures need to be static and > > > not programatically defined, like all other USB and PCI > > > drivers are handled. > > > - module reference counting. Are you sure you got it all right > > > for the individual modules that attach to the bus? I don't > > > see any reference counting happening, is that correct? > > > > For this round, I want to concentrate on just the vmbus driver. So, > > module reference counting is I don't think an issue for the vmbus driver > > given that the driver is not unlodable. Once I am done with the vmbus driver > > I will address the module reference counting issues for other drivers. > > No, I am referring to the module reference counting of the bus drivers > that register with the vmbus core. You aren't doing that at all, and > you probably need to make sure that this isn't needed. That is > concentrating on the vmbus driver. Ok; I will look into this. > > > I will also address your comment on static initialization hv_driver instances > > as part of other driver cleanup. > > No, please do this now as it will show how to properly interact with the > vmbus core code in the correct manner. Hopefully that will be correct, > but I have a feeling that it will show you some places in the API that > need to be changed... Will do. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
