Hi Julien,
> On 16 Oct 2023, at 15:38, Julien Grall <jul...@xen.org> wrote:
>
>
>
> On 16/10/2023 14:31, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 16 Oct 2023, at 11:07, Julien Grall <jul...@xen.org> wrote:
>>>
>>> Hi,
>>>
>>> On 13/10/2023 16:24, Federico Serafini wrote:
>>>> Add missing parameter names, no functional change.
>>>> Signed-off-by: Federico Serafini <federico.seraf...@bugseng.com>
>>>> ---
>>>> xen/drivers/passthrough/arm/smmu.c | 6 +++---
>>>
>>> This file is using the Linux coding style because it is imported from
>>> Linux. I was under the impression we would exclude such file for now.
>>>
>>> Looking at exclude-list.json, it doesn't seem to be present. I think this
>>> patch should be replaced with adding a line in execlude-list.json.
>> I think that during one of the discussions we said that this file already
>> deviated quite a lot from the status in Linux and we wanted to turn it to
>> Xen coding style in the future hence it is not listed in the exclude file.
> AFAIK the SMMUv{1, 2} code didn't deviate very much from Linux. I can't tell
> about the SMMUv3.
True that i had the v3 code in mind, we might not want to do that for v1/2 you
are right.
>
>> At the end having a working smmu might be critical in a safety context so it
>> will make sense to also check this part of xen.
> I don't buy this argument right now. We have files in exclude-lists.json that
> I would consider critical for Xen to run (e.g. common/bitmap.c,
> common/libfdt). So if you want to use this argument then we need to move
> critical components of Xen out of the exclusion list.
I am sure we will at some point for runtime code but we cannot do everything on
the first shot.
I was not meaning to do that now but that it is something to consider.
Cheers
Bertrand
>
> Cheers,
>
> --
> Julien Grall
