Kofi,
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.

Regards,
Fabrizio


On Wed, Jul 4, 2018 at 9:38 PM, <[email protected]> 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
> DATA61 | CSIRO
>
>
> _______________________________________________
> Devel mailing list
> [email protected]
> https://sel4.systems/lists/listinfo/devel
>
>
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel

Reply via email to