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

Re: [Xen-devel] behavioral change due to new elf code

Jan Beulich wrote:
>>>> Gerd Hoffmann <kraxel@xxxxxxx> 09.02.07 15:00 >>>
>> Jan Beulich wrote:
>>> But wouldn't that change behavior for domU-s then in an undesirable way?
>> Why?  dom0 and domU should have the same behavior ...
> I didn't check how the old domU-related tools code behaved here, I just
> assumed the new code was based more on the old tools code than the
> hypervisor one, and hence old behavior might have been the one I had
> just seen.

Old domU builder was cut&pasted from old dom0 builder three years ago ;)

> Regardless of that, the function shouldn't return here, but rather
> continue the loop.

No, the function parses just one note, the loop is one level up.

>>> Even better, I would think, would be to split the note namespace to
>>> distinguish
>>> - general required notes
>>> - general optional notes
>>> - dom0 required notes
>> Point being?  I'm not aware of any dom0-required note.  And I don't
>> think splitting into required and optional is useful, especially as this
>> is arch-dependent ...
> To e.g. catch notes the presence of which is necessary (i.e. a newer
> hypervisor will misbehave in its absence), but ignore such that only
> provide hints in certain directions.

I don't think there are such notes.  domU's are supposed to be
compatible in both directions.

> At present I also don't know of any dom0 required note, yet if any
> splitting is done, then all possible (i.e. foreseeable) groups should be
> allowed for. As you say, the list should also include an arch-specific
> range.

Shouldn't happen.  Starting with 3.0.3 dom0 kernel has no hypervisor
dependencies any more, only xen kernel and tools must match version-wise.


Gerd Hoffmann <kraxel@xxxxxxx>

Xen-devel mailing list



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