unsubscribe linux-kernel At 2011-04-27 10:31:18，"KY Srinivasan" <kys@xxxxxxxxxxxxx> wrote: > > >> -----Original Message----- >> From: Greg KH [mailto:greg@xxxxxxxxx] >> Sent: Tuesday, April 26, 2011 6:46 PM >> To: KY Srinivasan >> Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; >> devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; Haiyang Zhang; >> Abhishek Kane (Mindtree Consulting PVT LTD) >> Subject: Re: [PATCH 08/25] Staging: hv: vmbus_driver cannot be unloaded; >> cleanup accordingly >> >> On Tue, Apr 26, 2011 at 09:20:25AM -0700, K. Y. Srinivasan wrote: >> > The vmbus driver cannot be unloaded; the windows host does not >> > permit this. Cleanup accordingly. >> >> Woah, you just prevented this driver from ever being able to be >> unloaded. > >It was never unloadable; while the driver defined an exit routine, >there were couple of issues unloading the vmbus driver: > >1) All guest resources given to the host could not be recovered. > >2) Windows host would not permit reloading the driver without >rebooting the guest. > >All I did was acknowledge the current state and cleanup >accordingly. This is not unique to Hyper-V; for what it is worth, >the Xen platform_pci driver which is equivalent to the vmbus driver >is also not unlodable (the last time I checked). > >> >> That's not a "cleanup" that's a major change in how things work. I'm >> sure, if you want to continue down this line, there are more things you >> can remove from the code, right? >> >> What is the real issue here? What happens if you unload the bus? What >> goes wrong? Can it be fixed? > >This needs to be fixed on the host side. I have notified them of the issue. > >> >> This is a pretty big commitment... > >These drivers only load when Linux is hosted on a Hyper-V platform; >I am not sure why it is a "big commitment" given that the host does not >permit reloading this driver without rebooting the guest. > >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/ > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
