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 14:49, Philippe Gerum wrote:
>> 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.
>> 
>
> Yes, we need to align on this. Do you have your workflow documented
> anywhere?

Terser on the kernel side compared to libevl unfortunately, written
years ago but the basics did not change.

https://v4.xenomai.org/devprocess/index.html

> Then blame it on me that I didn't read that. I only followed
> intuitively reasonable patterns for many years now to ensure that
> dovetail is broadly tested and based on recent stable versions before it
> is released.
>

I do acknowledge this as a valuable effort, of course. We just need to
keep flexibility at the other end of the line as well, because as you
already know, we have to deal with out-of-tree issues vs upstream code
churn, an integration effort ongoing on the evl side in order to align
as intimately as possible with upstream by reusing its infrastructure,
and only few resources to do all of that.

So let's have an open conversation with anyone interested in
participating to it, about what can be improved in the existing process
- which was laid out in the early stages of the evl development when the
only dovetail user was evl. What made it flexible once may have become a
liability in some aspects, we can and should address these issues.

-- 
Philippe.