[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC] stubdom: Change vTPM shared page ABI
On Wed, 2012-11-28 at 22:22 +0000, Matthew Fioravante wrote: > On 11/28/2012 03:46 PM, Konrad Rzeszutek Wilk wrote: > > We could cop out and just name this new driver differently. Then > > we would not have to deal with the older ones. > I've already done that with my patch on the linux mailing list. The old > frontend driver name was tpm_xenu.ko, the new one is xen-tpmfront.ko. The name of the driver module isn't really relevant here, what matters is the name component of the xenstore paths used to trigger the creation the front and back devices, if they end up loading mutually incomprehensible versions of front and back then I expect that the failure case will be pretty hard to diagnose. The code I'm talking about is a handful of lines in both front and back, with $OTHEREND substituted as appropriate: err = xenbus_printf(xbt, dev->nodename, "feature-protocol-v2", "1"); if (err) { message = "writing feature-protocol-v2"; goto abort_transaction; } ... if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-protocol-v2", "%d", &val) < 0) { printk(KERN_WARN "Warning: $OTHEREND does not appear to support feature-protocol-v2\n"); printk(KERN_WARN "Perhaps it is running the obsolete out of tree vtpm driver?\n"); return -EFOOBAR; } Tweak the actual wording to taste. If there is a better/more descriptive name for the new protocol than "protocol-v2" that would be better, or you could put the 2 into the value (e.g. protocol = 2) and check via that instead (a bit more future proof perhaps?). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |