Re: Dovetail on risc-v: Testing strategy, managing efforts for forward porting

On 29.05.26 12:08, Philippe Gerum wrote:
> 
> Florian Bezdeka <[email protected]> writes:
> 
>> Hi Philippe,
>>
>> I'm currently waiting for a v8 of Tobias' risc-v implementation. A
>> couple of minor things still need fixing, but overall I would say that
>> we are looking good - ready for merging - assuming that currently
>> running tests are successful.
>>
> 
> Really nice stuff, thanks to anyone involved.
> 
>> From my point of view there is one issue left, that needs a discussion:
>> Testing and forward porting in the future.
>>
>> Up to now I was able to test all architectures using cobalt / x3. That
>> will change now, as we don't have risc-v support in x3.
>>
>> I see the following options:
>>
>> 1: Additionally forward port linux-evl in the future, so that we can run
>> tests against risc-v using x4. Additional effort for me, especially
>> because we don't have an in-house user for that. Can you estimate how
>> much time it takes you to forward port linux-evl in comparison to linux-
>> dovetail?
>>
> 
> Porting evl to a new arch kernel-wise is fundamentally trivial, the real
> work is done by Dovetail. For every currently supported arch, the amount
> of arch-specific evl code is 60 lines of C, merely wrappers in headers
> (arch/*/include/asm/evl/*.h). Tobias already contributed the few bits
> libevl needs to support risc-v.
> 
>> 2: Add risc-v support to x3 as well. To my understanding there were no
>> plans yet, but it might be worth it to limit forward porting efforts. I
>> could focus on x3 for testing. This might also help to compare risc-v
>> against the other architectures.
>>
> 
> Although this may require a little more effort compared to x4, such port
> would still be tractable since Dovetail does most of the work here as
> well. Adding risc-v support to x3 is Jan's call.
> 
>> 3: Ignore risc-v during forward porting. Yes, this option exists, but I
>> don't consider it as a real / valid option.
>>
> 
> Neither do I. Merged implies maintained.
> 
>> 4: Merge the risc-v support into linux-evl. That would make risc-v
>> support exclusive to evl, where we could already test it. Would that be
>> an valid option for the evl side?
>>
> 
> No, I believe that we can deal with one arch more such as risc-v in the
> Dovetail maintenance process. Besides, we really want the generic
> Dovetail code to be shared by all architectures, otherwise this would
> become a maintenance nightmare for the risc-v port.
> 
>> Any additional option available, that I missed?
>>
> 
> I'd say, the simpler the better. Today, enabling risc-v for x4 would be
> straightforward while keeping the current maintenance model for Dovetail
> mostly unaffected.  Granted, forward porting to the latest kernel
> release may require a bit more work in order to maintain the risc-v part
> too, but my understanding is that Tobias is willing to help with this in
> the long term. AFAICS, the arch-specific part in risc-v for Dovetail is
> fairly reasonable in size as well.
> 
> So, first step would be to merge the Dovetail risc-v support into
> linux-dovetail like other supported archs, enabling it for x4/evl in the
> same move. It could be enabled for x3 next, when time allows on your end
> if desired.
> 

To my understanding, Florian's concerns are not about the first-time
enabling or risc-v but its future testing when going to a new kernel
version. While arch-wise, most work is done in dovetail, testing would
only be possible once linux-evl is ported to a new kernel as well. And
that porting is widely arch-agnostic but for other reasons (drivers
e.g.) quite some generic effort.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center