[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6E21E5352C11B742B20C142EB499E0481E9474@TK5EX14MBXC128.redmond.corp.microsoft.com>
Date: Mon, 9 May 2011 12:35:46 +0000
From: KY Srinivasan <kys@...rosoft.com>
To: Greg KH <greg@...ah.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>
Subject: RE: various vmbus review comments
> -----Original Message-----
> From: Greg KH [mailto:greg@...ah.com]
> Sent: Sunday, May 08, 2011 11:05 PM
> To: KY Srinivasan
> Cc: gregkh@...e.de; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; virtualization@...ts.osdl.org
> Subject: Re: various vmbus review comments
>
> On Mon, May 09, 2011 at 01:46:56AM +0000, KY Srinivasan wrote:
> > > - the instances of hv_driver structures need to be static and
> > > not programatically defined, like all other USB and PCI
> > > drivers are handled.
> >
> > Done. You had expressed some concern that this would expose some issue
> > with the core vmbus driver (which is what I want to concentrate on this
> > go around). I have done this for both the block driver and the mouse driver
> > and I am pretty sure I can do the same with the network driver. I have not
> > currently done this for the network driver, since the number of patches I have
> > to submit is already very large.
>
> Ok, but it shouldn't be a major change to the code, right?
Right, it is not. I will submit code for the net driver after I am done with this patch-set.
>
> > > - 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?
> >
> > I have already exchanged an email with you on this. To summarize, it
> > does not look like there is a problem
> >
> > > - fix the sparse warnings.
> > Mostly done; most of the errors are in the base kernel coming out of
> > the macro page_to_pfn()
> >
> > > - fix the use of volatile in the ring buffer code. It should
> > > not be needed and if you are relying on it, then the code is
> > > wrong.
> >
> > You are right; all accesses were already serialized with a spin lock and the
> > Volatile attribute was unnecessary.
> >
> > > - fix the namespace on the ringbuffer code to show that it
> > > really is only for the hyperv bus code internally.
> >
> > Done.
> >
> > >
> > > That should be enough for at least one more set of patches for you all
> > > to work on :)
> >
> > Greg,
> >
> > I have had so much fun cleaning up these drivers that I lost track of the patch
> count.
> > I have addressed all the issues you have raised in addition to some other
> cleanup
> > that I was doing since about a week. As I look at the patch-set, I have little over
> > 200 patches. If it is ok with you, I would like to send them as a single set. Let me
> know
> > what you prefer. I need to circulate these patches internally before I can send
> them out.
> > I should be able to send these out early next week.
>
> A single set is fine, if that's what you want to do, I can handle that
> amount as long as they all build all along the way and don't break
> anything.
Thanks Greg.
Regards,
K. Y
--
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