Re: XTF-on-ARM: Bugs

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Christopher,

> On 22 Jun 2022, at 21:44, Christopher Clark <christopher.w.clark@xxxxxxxxx> 
> wrote:
> 
> On Wed, Jun 22, 2022 at 9:40 AM Bertrand Marquis
> <Bertrand.Marquis@xxxxxxx> wrote:
>> 
>> Hi Andrew,
>> 
>>> On 22 Jun 2022, at 17:28, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> wrote:
>>> 
>>> On 22/06/2022 13:32, Bertrand Marquis wrote:
>>>> Hi Andrew and Christopher,
>>>> 
>>>> I will not dig into the details of the issues you currently have
>>>> but it seems you are trying to re-do the work we already did
>>>> and have been using for quite a while.
> 
> Hi Bertrand - I apologise if it seems that way, and for the pace of
> this being slower than you had been expecting to see.
> I don't think I have actually been re-doing it and I'm grateful that
> you have made your team's work available. I am working to get what you
> need integrated into the upstream.

We have not been informed of anything or requested to review any
patch you are working on.
Only information we see is a claim that there is a bug.

> 
>>>> Currently we maintain the xtf on arm code in gitlab and we
>>>> recently rebased it on the latest xtf master:
>>>> https://gitlab.com/xen-project/people/bmarquis/xtf
>>>> 
>>>> If possible I would suggest to start from there.
> 
> Thanks - I will add this to the sources I am working with.

Ok

> 
>>> 
>>> Sorry to be blunt, but no. I've requested several times for that series
>>> to be broken down into something which is actually reviewable, and
>>> because that has not been done, I'm doing it at the fastest pace my
>>> other priorities allow.
>> 
>> You have not requested anything, we have been asking for a year
>> what we could do to help without getting any answer.
> 
> At Andy's request I had been looking into verifying the minimal
> necessary pieces to get the 32-bit Arm platform implementation to
> support a minimal stub test and also the XTF infrastructure (eg.
> printf, xtf return code reporting) that wasn't present in the posted
> work. The aim for doing that work was to build my familiarity with it
> and inform judgement involved in ensuring that the initial pieces that
> are merged into XTF have a maintainable structure to support each of
> the architectures (and configurations of each) that we need.
> It's taken longer than I wanted and it is clear that there is urgency
> to getting 64-bit Arm support integrated.

So you do not want our help and our code in its current form is not acceptable.

> 
>> 
>>> 
>>> Notice how 2/3 of the patches in the past year have been bits
>>> specifically carved out of the ARM series, or improvements to prevent
>>> the ARM series introducing technical debt. Furthermore, you've not
>>> taken the "build ARM in CI" patch that I wrote specifically for you to
>>> be part of the series, and you've got breakages to x86 from rebasing.
>> 
>> Which patch ? Where ? There was no communication on anything like that.
>> 
>>> 
>>> At this point, I am not interested in seeing any work which is not
>>> morphing (and mostly pruning) the arm-wip branch down into a set of
>>> clean build system modifications that can bootstrap the
>>> as-minimal-as-I-can-make-it stub.
>> 
>> You cannot expect us to poll on all the possible branches that you are 
>> creating
>> and simply rework what we did when you do something on some branch.
>> 
>> We went through what you requested using GitHub and asked you at almost all
>> Xen Community Call what we could do to go further without getting any answer.
> 
> I will continue to be reachable via the Community Calls. I will have a
> better understanding of what steps are needed next after reviewing the
> branch that you have posted.
> 
>> You are not interested in us contributing to XTF, this is understood.
> 
> No, that's really not the case; your contributions are highly valued.
> 
> There's a gap that needs to be closed here between the needs of the
> contributors (ie. you guys), to have platform support working and
> ability to make incremental contributions for new tests, and what the
> maintainer is looking for: a structure that implements an intended
> design -- that is difficult for contributors to know without having
> documentation for it, which is again time-consuming to produce --
> supporting the many target configurations in a coherent fashion, and
> introduced in small, concise logical steps. It's compounded by the
> fact that this is intricate system software where hardware
> platform-specific details are critical for reviewers and contributors
> to understand and implement exactly correctly.
> 
> So: I'm working on closing the current gap, aiming to make meaningful
> progress in the short term and can communicate with you more clearly
> as to the status of that in the coming weeks.
> I also think that once the initial platform support is merged, ongoing
> contributions will be both easier to produce and easier to review, to
> the advantage of all.

We will wait for all this to be available and at this stage we will check
if we use it or if we keep our own fork.
XTF porting was done as a base to develop Xen tests and, as it is
 now redesigned and we have no idea how, I will not have resources
anymore to assign on work on this.

All this could have been done in the open, discussing the needs and
involving the people who have tried to make this happen in the first place.

Cheers
Bertrand