regression with c/s 21223

[Jim Fehlig <jfehlig@novell.com>]

Hi Keir,

Unfortunately, my fix for losing device config [1] has caused duplicate
devices to appear when successfully starting a managed domain that uses
tapdisk :(. 

# xm li -l domu1 | grep tap
        (tap2
            (uname tap:aio:/mnt1/images/domu1/disk0)
# xm start domu1
# xm li -l domu1 | grep tap
        (tap2
            (uname tap:aio:/mnt1/images/domu1/disk0)
        (tap
            (uname tap:aio:/mnt1/images/domu1disk0)

This particular host does not have blktap2 driver so blktap1 is used
instead.  (NB: I do not see the problem when using blktap2, but we are
not yet supporting it.)

c/s 21223 attempted to make to_sxp() consult the stored config if no
running config was found for a given device class.  tap2 vs tap provides
an interesting twist.  If blktap2 dev controller is consulted (cls ==
tap2), no running config is returned since the device is really being
handled by blktap1.  The existing config is then consulted, in which
case a blktap2 (tap2) device is found.  When blktap1 controller is
consulted (cls == tap), it returns running config found in xenstore
resulting in duplicate devices.

Frankly, I'm not sure how best to handle this case.  The current
philosophy seems to be treat all 'tap:foo' devices as blktap2 (see c/s
19874 - author cc'd), but fall back to blktap1 if blktap2 is not found
when domU is started.  I'm certainly having problems differentiating
between the two in to_sxp().

Any suggestions on how to prevent the bug reported in [1] without this
new regression?

Thanks,
Jim

[1] http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01127.html