RE: [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id tomod_devicetable.h

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:greg@xxxxxxxxx]
> Sent: Tuesday, August 23, 2011 10:59 PM
> To: KY Srinivasan
> Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; Haiyang Zhang
> Subject: Re: [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id to
> mod_devicetable.h
> 
> On Wed, Aug 24, 2011 at 12:44:38AM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg@xxxxxxxxx]
> > > Sent: Tuesday, August 23, 2011 6:42 PM
> > > To: KY Srinivasan
> > > Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; Haiyang Zhang
> > > Subject: Re: [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id to
> > > mod_devicetable.h
> > >
> > > On Fri, Jul 15, 2011 at 10:45:51AM -0700, K. Y. Srinivasan wrote:
> > > > In preparation for implementing vmbus aliases for auto-loading
> > > > Hyper-V drivers, define vmbus specific device ID.
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx>
> > > > Signed-off-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
> > > > ---
> > > >  include/linux/mod_devicetable.h |    7 +++++++
> > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/include/linux/mod_devicetable.h
> > > b/include/linux/mod_devicetable.h
> > > > index ae28e93..5a12377 100644
> > > > --- a/include/linux/mod_devicetable.h
> > > > +++ b/include/linux/mod_devicetable.h
> > > > @@ -405,6 +405,13 @@ struct virtio_device_id {
> > > >  };
> > > >  #define VIRTIO_DEV_ANY_ID	0xffffffff
> > > >
> > > > +/*
> > > > + * For Hyper-V devices we use the device guid as the id.
> > > > + */
> > > > +struct hv_vmbus_device_id {
> > > > +	__u8 guid[16];
> > > > +};
> > >
> > > Why do you not need a driver_data pointer here?  Are you sure you aren't
> > > ever going to need it in the future?  Hint, I think you will...
> >
> > I am not sure I am following you here; the guid is the device ID and it is
> > guaranteed to remain the same. What is the driver _data pointer here
> > you are referring to here.  While some device id have the _data pointer,
> > there are others that don't - for instance struct virtio_device_id. In
> > our case, I am not sure how I would use this private pointer.
> 
> You use it like all other drivers use it, only if needed.

Fair enough; the point is I am not sure how I would use it.

> 
> Hint, I think you need to use it in your hv_utils driver, it would
> reduce the size of your code and simplify your logic.

Could you expand on this. Currently the util driver handles a bunch 
services that have their own guids - and these have been included
in the idtable. How would having the pointer simplify this code. 
I looked at the usage of this in PCI and it appears to be for supporting
dynamic  IDs for existing drivers. I am not sure if this is applicable to the util
driver. First, I am not sure if there will be additional services being 
packaged into util driver and secondly, even if I implement this scheme
of being able to dynamically add new IDs, we still would need to add the
code to the driver to handle the new service. In fact not a whole lot of 
code is shared amongst the services that are currently packaged as the
util driver. 

Regards,

K. Y

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/