[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] wrong io/tpmif.h made it into upstream Linux

>>> On 26.09.13 at 16:45, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Sep 26, 2013 at 03:17:42PM +0100, Jan Beulich wrote:
>> >>> On 26.09.13 at 13:52, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > in the course of reviewing the hypervisor side of this (i.e. the
>> > canonical copy of the header) I had requested some renames,
>> > and they had also been carried out there. Why did this not get
>> > adjusted _before_ hitting Linus'es tree? It's particularly strange
>> > because this can't be because different people were doing one
>> > side and the other...
> That is something Daniel will have to tell. But I am wondering if
> the patches were posted, but just never picked up (ie, lost in
> the Xen 4.3 release?).

No, 4.3 has properly named things in io/tpmif.h.

>> Additionally using xen:vtpm as module alias collides with the v1
>> implementation too afaict. Was avoiding conflicts with the old
> OK, but there is no v1 upstream and never will be. Would it
> be possible for the XenClassic kernels to mesh the classic
> v1 and the v2 implementation in one?

The interfaces are totally different, so having a new driver is the
right thing. But obviously the new frontend shouldn't get loaded
against a device drive by an old backed and vice versa.

Furthermore I have no clue whether there is a way to distinguish
both interfaces without having a proper XenBus identifier.

>> interface also not being considered here at all? Afaict the
>> backend also would need to announce itself differently from
>> the v1 one to xenbus...
> I think that was covered. It announces itself as vtpm but looks
> for "feature-protocol-v2". If that is not there it will not attach
> itself to the backend.
> I thought that was discussed in the review at length months ago?

Possible, but tying this to a secondary node is the wrong approach
afaict, as that way (if you so happen to have them) both frontend
drivers will get loaded upon a vtpm device appearing. And while
the v2 one will know to look for the extra node, the v1 one clearly
won't bail if that node is there.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.