From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50162 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOfHM-00029B-4I for qemu-devel@nongnu.org; Tue, 15 Jun 2010 19:10:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOfHI-00057Q-Tf for qemu-devel@nongnu.org; Tue, 15 Jun 2010 19:10:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42348) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOfHI-00057B-Ma for qemu-devel@nongnu.org; Tue, 15 Jun 2010 19:10:44 -0400 Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() From: Alex Williamson In-Reply-To: <201006160001.31205.paul@codesourcery.com> References: <20100614054923.879.33717.stgit@localhost.localdomain> <201006152255.48221.paul@codesourcery.com> <1276641184.12015.932.camel@x201> <201006160001.31205.paul@codesourcery.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 Jun 2010 17:10:34 -0600 Message-ID: <1276643434.12015.940.camel@x201> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: chrisw@redhat.com, kvm@vger.kernel.org, Jan Kiszka , Markus Armbruster , qemu-devel@nongnu.org, avi@redhat.com, kraxel@redhat.com 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