Re: [Xen-devel] [RFC PATCH V3] Implement 3-level event channel in Xen

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 27/02/2013 23:19, "Wei Liu" <wei.liu2@xxxxxxxxxx> wrote:

> On Wed, Feb 27, 2013 at 07:49:34PM +0000, Keir Fraser wrote:
>> On 27/02/2013 17:01, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> 
>>>>>> On 27.02.13 at 15:33, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
>>>> Keir, Jan, Ian and David, are you happy with this design in general? I
>>>> would
>>>> like to have explicit ACK / NACK on this if possible, as feature freeze for
>>>> 4.3 is quite close now.
>>> 
>>> The patches look reasonable (apart from the comments I just gave
>>> on some of them), but other than Keir I'm not that eager to see this
>>> one go in for 4.3 in order to then likely be replaced by an
>>> implementation of David's design in the 4.4 cycle.
>> 
>> If this went in for 4.3, a re-design would really have to be implemented and
>> measurably prove its worth to make it in as another replacement.
> 
> Even this design does not go in for 4.3, any new design will still have
> to be implemented and measurable prove its worth, as with this design.

I believe there's a requirement to solve the dom0 event-channel limit for
4.3. Either of the proposed designs obviously solves that, without need for
implement and test. Of course, we need to do that to test for correctness
and performance regressions anyway. But I mean with that primary requirement
satisfied, yet another evtchn ABI really then has to have some compelling
advantages to get committed.

 -- Keir

> The value of this design lies in that a) it's straight forward, easy to
> prove its correctness (or wrongness), b) it meets our need for now, c)
> a new interface will always be necessary, be it this design or any other
> design, d) it buys time for any better designs to become mature.
> 
> I understand your (and Jan's) concern for burdens of maintaining
> different ABIs, that's why the interface has been made to allow user to
> query enabled / supported ABIs. If we need to add / remove ABIs, it's
> just a matter of setting some feature bits.
> 
> I don't mean to push this design to get merged, it's up to maintainers
> to decide. Actually I'm fine with any decision. Explicit Ack / Nack will
> help me arrange my future work better.
> 
> 
> Wei.
> 
>>  -- Keir
>> 
>>> Jan
>>> 
>> 
>> 



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