Re: [Xenomai-help] How can I make Xenomai share a mii bus with the kernel?

[Philippe Gerum <rpm@xenomai.org>]

Michael Galea wrote:
> I wonder if someone can suggest an approach to the following problem.
> 
> We need to use xenomai to manage devices on the mii bus.  The mii bus 
> has PHYs managed by linux. What is the best way of providing access to 
> both linux and xenomai?
> 
> I know that before xenomai "loads", I can simply access the mii bus from 
> linux.  But after xenomai loads, is the right answer to make the linux 
> function that reads the phy migrate into the xenomai domain and contend 
> for the bus there?
>

Problem is that Xenomai does not really compete with Linux, it preempts it
bluntly and rudely when it needs so, regardless of the Linux locking. So regular
Linux users of the PHY layer would start having problems, and your board would
happily jump out of the window.

Therefore, you would have to analyze and fix every callee from net/phy (and on)
to use Xenomai locking, instead of plain Linux locking constructs, at the very
least. Aside of the fact that this may be quite time-consuming and error-prone,
this would also de facto make the critical sections defined in the phy code
non-preemptible RT-wise, which may have some impact on the worst-case latency as
well. Sorry, this is co-kernel neighbourhood: we fancy behaving as masochistic
zombies around here.

Question: Is the Xenomai code calling into the phy layer a real-time beast, with
actual deadlines to be met, or not?

If yes, then you have no other choice than "ironing" the phy management code, so
that it can be entered from both the Linux and real-time spaces in a mutually
exclusive manner.

If there are no deadlines (lucky you), then you probably want to issue a request
(_not_ a function call, but some kind of APC) to the Linux space from your
Xenomai task (see rthal_apc_alloc and friends). But in the latter case, the
Xenomai task would lose any RT properties, because your code would likely want
to wait for completion of that request on the Linux side, most of the time.

The description above assumes your code lives in kernel space. In case that code
could live in userland, then you could use a more straightforward
implementation, based on a small RTDM driver forwarding PHY requests and sending
back the results to userland. Since Xenomai tasks in user-space may switch
automatically back and forth between the Linux and Xenomai domains, you would
not need to handle the quirks of APC handling. Still, you would not have any RT
guarantees for the call site, but maybe that's acceptable.

-- 
Philippe.