Thanks for your reply. 
Ok, I have implemented what I think is a clean fix until the new framework will be ready.

To avoid the libethdrivers to directly accessing the 'priv' field of the mux_sys->priv, I have added one more function to the mux_sys API: mux_sys_get_vaddr() that simply returns the vaddr of the mapped MUXC. I have then extended the size of the area mapped to include the entire 16Kb of the MUXC.

Then the libethdriver now uses the mux_sys_valid to check if the mux is available, and if so, used it to retrieve the vaddr of the MUXC. If not it proceed by privately mapping & unmapping the MUX when it's done.

My changes are in pull request #16: https://github.com/seL4/util_libs/pull/16

I have tested it on my build and it works.


On Wed, Jul 4, 2018 at 9:38 PM, <Kofidoku.Atuah@data61.csiro.au> wrote:

Hey Fabrizio​, I'm sorry we took so long to get back to you:

The underlying problem here is that we haven't yet finished defining and implementing a driver framework for our userspace code, so in order to satisfy dependencies, we began stuffing them into the io_ops struct. So since lots of devices depend on an initialized mux driver, what you see here is the result of that, unfortunately -- the good news is that we're currently defining a driver framework internally (https://docs.sel4.systems/seL4DriverAPI/ChildEnumeration.html is one of the draft pages of documentation -- but none of this is finalized) over the course of this year.

What I'd recommend is that you use the helper function, mux_sys_valid() in mux.h (https://github.com/seL4/util_libs/blob/master/libplatsupport/arch_include/arm/platsupport/mux.h#L35) inside of the ethernet driver, and map the whole 16K range inside of the IO-Ops initializer -- essentially what's going on there is that there's a dependency on the mux driver that's satisfied by the IO-Ops object.

Thanks very much for your patience,​ and this sort of thing should be cleaned up soon.

Yours truly,

Kofi Doku Atuah
Kernel engineer

Devel mailing list