Re: [PATCH v8 0/9] remove libxenctrl usage from xenstored

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.03.2025 14:27, Jürgen Groß wrote:
> On 06.03.25 14:13, Jan Beulich wrote:
>> On 06.03.2025 00:32, Stefano Stabellini wrote:
>>> On Wed, 5 Mar 2025, Juergen Gross wrote:
>>>> On 25.02.25 12:10, Juergen Gross wrote:
>>>>> Ping? Especially ...
>>>>>
>>>>> On 04.02.25 12:33, Juergen Gross wrote:
>>>>>> Xenstored is using libxenctrl for only one purpose: to get information
>>>>>> about state of domains.
>>>>>>
>>>>>> This patch series is removing that dependency by introducing a new
>>>>>> stable interface which can be used by xenstored instead.
>>>>>>
>>>>>> There was a RFC series sent out 3 years ago, which I have taken as a
>>>>>> base and by addressing all comments from back then.
>>>>>>
>>>>>> The main differences since that RFC series are:
>>>>>>
>>>>>> - Instead of introducing an new main hypercall for a stable management
>>>>>>     interface I have just added a new domctl sub-op, as requested in 
>>>>>> 2021.
>>>>>>
>>>>>> - I have added a new library libxenmanage for easy use of the new
>>>>>>     stable hypervisor interface. Main motivation for adding the library
>>>>>>     was the recent attempt to decouple oxenstored from the Xen git tree.
>>>>>>     By using the new library, oxenstored could benefit in the same way as
>>>>>>     xenstored from the new interface: it would be possible to rely on
>>>>>>     stable libraries only.
>>>>>>
>>>>>> - Mini-OS has gained some more config options recently, so it was rather
>>>>>>     easy to make xenstore[pvh]-stubdom independent from libxenctrl, too.
>>>>>>
>>>>>> Please note that the last 4 patches can be committed only after the
>>>>>> related Mini-OS patch "config: add support for libxenmanage" has gone in
>>>>>> AND the Mini-OS commit-id has been updated in Config.mk accordingly! The
>>>>>> Mini-OS patch has been Acked already, so it can go in as soon as patch
>>>>>> 5 of this series (the one introducing libxenmanage) has been committed.
>>>>>>
>>>>>> As patches 1 and 2 change current behavior, Jan didn't want to give his
>>>>>> Ack (he didn't reject the patch either). So I'm asking other "Rest"
>>>>>> maintainers to look at those patches specifically.
>>>>>
>>>>> ... patches 1 and 2 could need an additional opinion.
>>>>
>>>> And another ping.
>>>>
>>>> One of Andrew, Stefano, Julien, Roger, Anthony, Mical: Please have a look.
>>>>
>>>> The related discussion between Jan and me can be found here (patches 2 and 
>>>> 3):
>>>>
>>>> https://lore.kernel.org/xen-devel/20250107101711.5980-1-jgross@xxxxxxxx/
>>>
>>> I didn't do an in-details review but based on Jan's comments and your
>>> replies, I think they are an improvement. If someone else wants to do a
>>> proper review, they would be welcome.
>>>
>>> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>
>> I've taken the conservative approach and interpreted this as an ack for the
>> two patches in question only, rather than the entire series. Please indicate
>> if it was meant the other way around, as then the final 3 patches could also
>> go in.
> 
> Sorry, but please revert the last patch of this series you've committed
> already. As stated in the cover letter AND that patch, a Mini-OS patch and
> the bump of the Mini-OS commit in Config.mk are required in order to avoid
> build failures when trying to build the Xenstore-stubdom binaries.

Indeed, I overlooked this while preparing what to commit (while I remember
noticing it earlier on). Still it's probably sub-optimal to have a series
split in the middle like this.

Instead of reverting, let's bump the MiniOS ref in staging instead, as you
did suggest on Matrix.

Jan