> On Sep 5, 2019, at 04:36, Lars Kurth <[email protected]> wrote:
>
> On 05/09/2019, 09:33, "Juergen Gross" <[email protected]> wrote:
>
>> On 05.09.19 10:14, Andrew Cooper wrote:
>>> On 05/09/2019 08:49, Lars Kurth wrote:
>>>> On 05/09/2019, 08:41, "Rich Persaud" <[email protected]> wrote:
>>>>
>>>> On Sep 5, 2019, at 03:19, Jan Beulich <[email protected]> wrote:
>>>>
>>>> Forgive me asking, but why is this put up as an agenda item here?
>>>> IMO this is the kind of thing where you would send a proposal and
>>>> request feedback by email first, and put it up as an agenda item
>>>> here only if it got stalled there. (Apologies if I've overlooked
>>>> such a stalled thread.)
>>>
>>> If Xen community call topics are limited to escalations of xen-devel
>>> threads, then a new thread can be created for this topic. Xen community
>>> calls have also provided real-time, interactive feedback on candidate
>>> proposals, along with guidance on areas which need documentation before a
>>> formal proposal is made to xen-devel. Such agenda items are typically
>>> covered after all series and priority topics have been addressed.
>>>
>>> I don't mind having items such these on the agenda and to be fair have
>>> added similar items onto the agenda in the past.
>>> Clearly, they are forward looking [like an RFC], for which reason I tend to
>>> add them to the end of an agenda if there is a busy schedule
>>>
>>> Personally, on this specific item, it is not really clear what the
>>> questions are. In other words: is this about UUIDS/domain ids only, or is
>>> there something else.
>>
>> Requiring something to be blocked on xen-devel before we discuss it on
>> the call is monumentally short sighted, and off-putting for contributors.
>>
>> In this case, it is very definitely not the first time this problem has
>> been raised, as it is an XSA shaped elephant in the room. Its no secret
>> that id wraps cause problems, and while our security policy doesn't
>> comment on the matter, it also doesn't say "warning - stuff *will* break
>> in weird, wonderful, and security-relevant ways when domid's wrap".
>>
>> The order of the agenda is important, and I don't think this should be
>> at the top, but even if we only end up with 2 minutes to discuss it,
>> then so be it. (2 minutes of talking can still be far more valuable
>> than a weeks worth of emailing.)
>>
>> What is not acceptable is suggesting that it should be veto'd simply
>> because it is perceived to be a very fresh idea/query.
>
> I still think it would help if a short high level design would be posted
> on xen-devel first.
>
> I think that is a valid point and I agree. In the past when we had similar
> discussions often the outcome was not that clear and due to the nature of
> the calls the discussions were also not well reflected in the notes.
>
> So, there is an argument, that discussions typically are more productive when
> there is the possibility for some preparation or an e-mail thread to refer to.
We can defer the xenstoreless name service topic to the October monthly call.
For today's call, can we discuss the previously posted high-level design for
unification of the domB RFC with dom0less, as "domB mode" for disaggregation of
Xen's dom0?
- domB mode for dom0less (July 2019): https://lists.gt.net/xen/devel/557782
- domB RFC (June 2018): https://lists.gt.net/xen/devel/519367
Rich
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
