Am 14.10.2010 18:16, Philippe Gerum wrote:
> On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
>> Am 14.10.2010 17:42, Philippe Gerum wrote:
>>> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>>>> Philippe,
>>>> irqbench does not inherently depend on a third I-pipe domain. It is a
>>>> useful testcase, the only in our portfolio that targets a peripheral
>>>> device use case. In fact, it was only of the first test cases for Native
>>>> Please revert the removal and then cut out only the few parts that
>>>> actually instantiate an additional domain (i.e. mode 3.
>>> So, what do we do with this? Any chance we move to arch-neutral code for
>>> this test?
>> Arch-neutral is impossible due to the inherent hardware dependency. But
>> I'm waiting on some comments by Wolfgang on their work as that's
>> probably the best requirements source for multi-arch support.
> I mean that the bulk of the code could be made arch-neutral, with only
> callouts to solve the arch-dependent/uart issues. Typically, 16550's are
> not uncommon on powerpc, but we obviously don't program them via
> ioports. A second level of indirection could provide the entire chip
> handling, to fit other uarts, maybe?

If there are suitable UARTs around, refactoring the code accordingly and
maybe adding support for one of them as reference would be a good next
step. But first I would like to understand (or recall - I think Wolfgang
once explained it) the motivations for not going this path with the
gpiobench test and learn its requirements to avoid doing refactorings
twice or more.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to