On Tue, Aug 30, 2011 at 05:22:54PM +0000, KY Srinivasan wrote:

quoted

-----Original Message-----
From: Olaf Hering [mailto:olaf@aepfle.de]
Sent: Tuesday, August 30, 2011 8:49 AM
To: KY Srinivasan
Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
devel@linuxdriverproject.org; virtualization@lists.osdl.org
Subject: Re: [PATCH 0000/0046] Staging: hv: Driver cleanup

On Sat, Aug 27, K. Y. Srinivasan wrote:

quoted

	2) Handle all block devices using the storvsc driver. I have modified
	   the implementation here based on Christoph's feedback on my earlier
	   implementation.

The upgrade path from hv_blkvsc to hv_storvsc is difficult.

hv_storvsc does not provide the vmbus:hv_block modalias, so mkinitrd
does not know what module to choose when mkinitrd is called in a
previous kernel (like sles11sp1).


In a guest with both SCSI and IDE controllers the IDE disks are
discovered first, so the SCSI drives will also change their names.
Thats not a problem for data partitions because they could be mounted by
UUID or LABEL in fstab.
But its difficult to adjust /boot/grub/device.map for example because
the old  IDE drives do not provide an identifier. What is the best way
to make sure the rename from hd* to sd* in such config files is done
correctly? Is it safe to assume that all drives with a class_id of
32412632-86cb-44a2-9b5c50d1417354f5 are connected to IDE ports?

The class_id is invariant as we are returning the guid of the device under class_id.

So, if you see a IDE guid under class_id, you can be sure (a) it is an ide device and (b)
it is a device managed via the PV drivers.

quoted

localhost:~ # head /sys/bus/vmbus/devices/vmbus_0_{1,2,3,10,11}/class_id
==> /sys/bus/vmbus/devices/vmbus_0_1/class_id <==
{32412632-86cb-44a2-9b5c50d1417354f5}

==> /sys/bus/vmbus/devices/vmbus_0_2/class_id <==
{32412632-86cb-44a2-9b5c50d1417354f5}

==> /sys/bus/vmbus/devices/vmbus_0_3/class_id <==
{32412632-86cb-44a2-9b5c50d1417354f5}

==> /sys/bus/vmbus/devices/vmbus_0_10/class_id <==
{ba6163d9-04a1-4d29-b60572e2ffb1dc7f}

==> /sys/bus/vmbus/devices/vmbus_0_11/class_id <==
{ba6163d9-04a1-4d29-b60572e2ffb1dc7f}


In my test system, the IDE drives are now discovered twice, once by
hv_storvsc and once by libata:

This is a known (old problem). The way this was handled earlier was to have the 
modprobe rules in place to setup a dependency that would force the load of the
hyper-v driver (blk / stor) ahead of the native driver and if the load of the PV
driver succeeded, we would not load the native driver. In sles11 sp1, we had a rule for 
loading blkvsc. With the merge of blkvsc and storvsc, the only change we need to make
is to have storvsc in the rule (instaed of blkvsc).

Why do we need a rule at all?  Shouldn't the module dependancy stuff
handle the autoloading of the drivers properly from the initrd now that
the hotplug logic is hooked up properly?

What am I missing here?

Or is the hotplug code not working correctly?

greg k-h