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

Re: [Xen-devel] [HYBRID]: status update...



Wednesday, August 1, 2012, 6:21:57 PM, you wrote:

> On Wed, Aug 1, 2012 at 5:05 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> wrote:
>> On Wed, Aug 01, 2012 at 04:59:58PM +0100, George Dunlap wrote:
>>> On Wed, Aug 1, 2012 at 4:25 PM, Konrad Rzeszutek Wilk
>>> <konrad.wilk@xxxxxxxxxx> wrote:
>>> > On Wed, Aug 01, 2012 at 04:25:01PM +0100, George Dunlap wrote:
>>> >> I hope this isn't bikeshedding; but I don't like "Hybrid" as a name
>>> >> for this feature, mainly for "marketing" reasons.  I think it will
>>> >> probably give people the wrong idea about what the technology does.
>>> >> PV domains is one of Xen's really distinct advantages -- much simpler
>>> >> interface, lighter-weight (no qemu, legacy boot), &c &c.  As I
>>> >> understand it, the mode you've been calling "hybrid" still has all of
>>> >> these advantages -- it just uses some of the HVM hardware extensions
>>> >> to make the interface even simpler / faster.  I'm afraid "hybrid" may
>>> >> be seen as, "Even Xen has had to give up on PV."
>>> >>
>>> >> Can I suggest something like "PVH" instead?  That (at least to me)
>>> >> makes it clear that PV domains are still fully PV, but just use some
>>> >> HVM extensions.
>>> >
>>> > if (xen_pvh_domain()?
>>> >
>>> > if (xen_pv_h_domain()?
>>> >
>>> > if (xen_h_domain()) ?
>>> >
>>> > if (xen_pvplus_domain()) ?
>>> >
>>> > if (xen_pv_ext_domain()) ?
>>> >
>>> > I think I like 'pv+'?
>>>
>>> I could deal with pv+.  However, in general I dislike that kind of
>>> "now even better!" marketing.  PV+, EPV (Enhanced / extended PV), PVX
>>> (Extreme PV!) -- they all sound cool when they come out, but five
>>> years later, when they're not so new or sexy anymore, they all sound
>>> lame.  PVH is just descriptive -- it will always be PV with HVM
>>> extensions, so it will age much better. :-)
>>
>> How about pv_with_mmu_in_hvm_container_domain() ?
>>
>> Ok, that is a bit to lengthy. How about then:
>>
>> if (xen_pvhvm_ext_domain()) ?
>>
>> The 'if (xen_pvh_domain())' is just one characer short of 'xen_pv_domain()'
>> and one might not notice it. Perhaps then 'if (xen_pv_h_domain()' ?

> Hmm -- that's an interesting issue I hadn't thought of.  "PVHVM" has
> already been sort of taken by Stefano's extensions to allow Linux
> kernels booted in HVM mode to use some of the PV extensions.  I tend
> to think "xen_pvh_domain()" is probably OK, but maybe calling it
> "pvext" (or "pvhext") in the code, and "PVH" in documentation /
> stories?  Just using "pvext" everywhere could work as well; it's a
> little bit "now even better!", but not as much as pvplus.

Am i mistaken in saying that both "Hyrbid" and "PVHVM" are both targeting the 
same, but approaching it from a different base / direction (PV + HVM extensions 
versus HVM + PV extensions) ?
If that's the case, how far are these apart from meeting each other in the 
middle, and what would be the fundamental difference ?
It seems to be the full qemu container / emulated driver model availability on 
HVM + PV extensions ?

Just wondering if the naming should express that most explicit and fundamental 
difference (if there is one :-) ) ?



>  -George





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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