linux-kernel - Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110426232843.GA31184@kroah.com>
Date:	Tue, 26 Apr 2011 16:28:43 -0700
From:	Greg KH <greg@...ah.com>
To:	"K. Y. Srinivasan" <kys@...rosoft.com>
Cc:	gregkh@...e.de, linux-kernel@...r.kernel.org,
	devel@...uxdriverproject.org, virtualization@...ts.osdl.org
Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days.  In this patch-set we
> deal with the following issues:
> 
> 	1) Cleanup unnecessary state in struct hv_device and 
> 	   struct hv_driver to be compliant with the Linux
> 	   Driver model.
> 
> 	2) Cleanup the vmbus_match() function to conform with the 
> 	   Linux Driver model.
> 
> 	3) Cleanup error handling in the vmbus_probe() and 
> 	   vmbus_child_device_register() functions. Fixed a 
> 	   bug in the probe failure path as part of this cleanup.
> 
> 	4) The Windows host cannot handle the vmbus_driver being 
> 	   unloaded and subsequently loaded. Cleanup the driver with
> 	   this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it.  If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good.  But you should
follow-up with some driver structure changes like what Christoph said to
do.  After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

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/