Re: [dovetail][PATCH v2 0/4] ARM trap fixes and generic handling of trap nesting

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 12.11.26 13:59, Philippe Gerum wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 12.11.26 12:39, Florian Bezdeka wrote:
>>>> On Thu, 2026-11-12 at 12:30 +0100, Jan Kiszka wrote:
>>>>> On 12.11.26 12:25, Florian Bezdeka wrote:
>>>>>> On Thu, 2026-11-12 at 12:16 +0100, Jan Kiszka wrote:
>>>>>>> On 12.11.26 12:05, Florian Bezdeka wrote:
>>>>>>>> On Thu, 2026-11-12 at 11:31 +0100, Philippe Gerum wrote:
>>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I will share the lengthy test case as well once I'm done with stripping
>>>>>>>>>> it down further (if possible). What the tests already demonstrated is
>>>>>>>>>> that unpatched kernels crash.
>>>>>>>>>>
>>>>>>>>>> These patches here are almost completely generated. One of my few
>>>>>>>>>> contributions was to encode _TLF_OOBTRAP into oob_trap_regs. The idea
>>>>>>>>>> of having oob_trap_regs as a nesting detector came from the AI, though.
>>>>>>>>>>
>>>>>>>>>> As usual, AI is still rather verbose in descriptions and comments. Some
>>>>>>>>>> of them I already shortened, but most is still left. We can cut down
>>>>>>>>>> further, but I would first of all like to have another review round.
>>>>>>>>>>
>>>>>>>>>> While doing that, keep in mind that AI tends to ignore issues left and
>>>>>>>>>> right when being told to do a specific task. It may have simply missed
>>>>>>>>>> further preexisting issues or even created new ones now. Watch out!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It looks like patches 1-3 have landed into v6.18.Y already, which means
>>>>>>>>> that you are confident with those changes eventually.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Those patches should not go anywhere until they reached the latest
>>>>>>>> development branch. The common "upstream first" rule.
>>>>>>>>
>>>>>>>> Everything else will add a lot of confusion.
>>>>>>>
>>>>>>> The v6.18 application was experimental, to validate that the test suite
>>>>>>> passes on real hardware when all issues are addressed. Nothing is
>>>>>>> official in rebase branches until it is tagged, including those patches.
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>
>>>>>> Why not just push out a wip/ prefixed branch? That does not require to
>>>>>> temporary update branches looked at by different / more people.
>>>>>
>>>>> CI is not picking up such branches.
>>>>>
>>>>
>>>> Which is OK. Those branches should be tested only when requested
>>>> manually. The "internal" infrastructure has such a feature, while the
>>>> public one is missing that.
>>>>
>>>> Upstreaming was not considered yet as it highly reworked the xenomai-
>>>> images project. But maybe it's of interest now.
>>>>
>>>
>>> I'm not using anything internal. If you have a patch for the official
>>> one, please submit.
>>>
>>> But pushing to -rebase is also not a big deal because it is, well,
>>> rebasing, not stable.
>>>
>> 
>> The dovetail rebase branches feed the evl trees though, which follow a
>> rebasing model for a reason. Although I'm not concerned by the specific
>> patches I mentioned earlier which look sane so far (review is still
>> ongoing), let's keep in mind that dovetail rebase branches are not the
>> right place for unstable work. As Florian pointed out, wip/ should
>> preferred for this.
>
> Rebase branches were and are not stable until they are tested. This is
> what they exist for.

No, they don't. Rebase branches are only a workflow for evl which do not
assume that code might be unstable in there, only accepting that bugs do
exist.

> Once testing passed, we tag. This is also how I run
> all the stable versions I maintain. In most cased, the tagging goes
> straight on top, but I already had to fix up untagged branches in the
> past. Or rebase them once more because of further upstream releases.
>
> Now, if you ever tagged evl branches earlier than dovetail branches,
> that should be avoided in the future.

I'm unsure why the tagging issue is brought up, this is not the point
which is being discussed. The point is to refrain from changing the
semantics underlying the rebase branch arbitrarily, only to find out
that this may break the evl development that sparked the dovetail
development in the first place, nearly ten years ago.

I'm generally ok for improving the process, like getting help from an
LLM for the mechanical part of the maintenance, but let's do this with
every stakeholder on board, participating to the decision.

-- 
Philippe.