On Thu, Jun 16, 2011 at 01:16:42PM -0700, K. Y. Srinivasan wrote:
> Setup the newly introduced id_table for the blkvsc driver.:
>
> Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx>
> Signed-off-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
> Signed-off-by: Hank Janssen <hjanssen@xxxxxxxxxxxxx>
> ---
> drivers/staging/hv/blkvsc_drv.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/hv/blkvsc_drv.c b/drivers/staging/hv/blkvsc_drv.c
> index 3612574..5842db8 100644
> --- a/drivers/staging/hv/blkvsc_drv.c
> +++ b/drivers/staging/hv/blkvsc_drv.c
> @@ -802,10 +802,15 @@ static void blkvsc_request(struct request_queue *queue)
> }
> }
>
> +static const struct hv_vmbus_device_id id_table[] = {
> + { "hv_block" },
> + { "" }
> +};
Ick. Yeah, I was afraid of this :(
You are trying to use a "human" name here, which you could just use the
macro for the module name.
But, we don't care about the module name, we just care about what GUID
this driver says it supports. So put that in the driver, then use the
module alias for that GUID and have modprobe figure out what module to
load based on when the GUID is seen by the vmbus and exposed to
userspace through the hotplug event.
Think of the GUID as a PCI vendor/device/class signature, that's all it
is. None of this wierd "names" that you have to keep track of in the
core, and in the driver, and hope to keep them all in sync all the time.
So no, this isn't the way to do this sorry, please redo it like
PCI/USB/the entire rest of the kernel does it.
thanks,
greg k-h
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
