On Wed, 2010-06-16 at 00:01 +0100, Paul Brook wrote:
> > > I find this argument contradictory. The migration code already needs to
> > > check whether a device is compatible before it allows migration. The
> > > driver name is not sufficient to ensure compatibility, so I see no
> > > benefit in including it in the device address.
> >
> > See my comment above, I'm not seeing a sufficient argument about why
> > driver name matching is a false sense of security. If on an incoming
> > migration I'm able to match the source provided e1000.03.0/vmstate
> > against the target registered e1000.03.0/vmstate and hand off to the
> > e1000 driver to check version ids, you bet I'm feeling a lot more secure
> > than if I'm handing off to whatever happened to register 03.0/vmstate on
> > the target.
>
> I still say it should be the migration code that checks that both vmstate
> structures are for the same type of device. i.e. if necessary the device name
> should be embedded in the device state, not the device path.
The migration code would check that ("%s/%s", path, name) match. So
embedding the driver name into path gives us a per path namespace. Sure
the migration code could check ("%s/%s/%s, path, dev->info->name, name),
but should it be the migration code's responsibility to dig that out?
And if you think that i440FX-pcihost is a useful driver name, then we'd
have to figure out which driver names are useful. I think it's more
consistent to simply put them all there. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
