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 >>>> RTDM IIRC. >>>> >>>> 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. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
