Message-ID: <20110706150202.GA3353@kroah.com>
Date:	Wed, 6 Jul 2011 08:02:02 -0700
From:	Greg KH <greg@...ah.com>
To:	KY Srinivasan <kys@...rosoft.com>
Cc:	"gregkh@...e.de" <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Hank Janssen <hjanssen@...rosoft.com>
Subject: Re: [PATCH 15/77] Staging: hv: blkvsc: Add the appropriate
 MODULE_ALIAS() line

On Wed, Jul 06, 2011 at 02:55:12PM +0000, KY Srinivasan wrote:
> > > I think you mean MODULE_DEVICE_TABLE()?
> > 
> > Yes, sorry for the typo.
> > 
> > > I actually went down that path first
> > > adding code  to  file2alias.c for parsing the vmbus ID table. Given that this
> > approach
> > > would make it  impossible to support auto-loading of these drivers
> > > on many of the released kernels,
> > 
> > Wait, what?  What is a "released kernel"?  We are working on the
> > in-kernel patch, we don't care about older distros/releases for this
> > work at all.  Also, it doesn't make sense at all, why would the change I
> > asked for make any difference on older distros/kernels?
> 
> I understand we don't care here about older kernels and I will do what you
> have suggested. I just wanted to give you the rationale for choices I made:
> We are currently supporting older distros/kernels using these upstream bits.
> With the MODULE_ALIAS() approach, since I did not have to change any code
> outside the hv directory, this was possible. I was mostly concerned about 
> having to make changes to code outside the hv directory and figuring out 
> how to build and propagate these changes (file2alias.c) in older kernels. 

You create a patch like any other patch and give it to the people who
are stuck with those older kernels.  It shouldn't be that hard, and it
also shouldn't be something that matters for this mainline work either.

> > > I chose to go with the MODULE_ALIAS() macro that did not need any
> > > changes outside our drivers. In both methods, the formatting of the
> > > name is bus specific since I would be writing the code to parse the
> > > table in file2alias.c.
> > 
> > Yes, that is what is needed to be done.
> > 
> > > Granted, I have been quite unimaginative in my alias names, but I
> > > thought they were reasonably descriptive. If at all possible, for the
> > > reasons listed above, I would prefer to use the MODULE_ALIAS() macro
> > > (I could embed all or part of the guid in the alias). Let me know.
> > 
> > Please do the correct thing and use MODULE_DEVICE_TABLE().
> 
> We have four drivers now excluding vmbus and soon we will have only three
> drivers with the merge of block and stor drivers. Would you still recommend I use the
> full guid to name these drivers.

Yes, why not?

> Rather than embedding the entire 128bit guid in module aliases, I was
> thinking of setting up a more reasonable namespace for these drivers
> (like what virtio has done for instance). Let me know if this is ok
> with you if I took that route (mapping the guid to small integers and
> having these integers be used in alias strings).

What's the big deal of having a large number as an alias?  Is there some
constraint here that I am not aware of?

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

Powered by blists - more mailing lists