Obtaining and accessing device abstractions in L4Re

[Matthias Lange]

Hi Paul,

On 07/04/2017 11:11 PM, Paul Boddie wrote:
> Hello,
> 
> I've been trying to write some drivers in L4Re, starting out with a GPIO 
> driver for a currently-unsupported board, and I think I have mostly understood 
> the concepts involved. Fortunately, there are already a couple of drivers to 
> borrow ideas from...
> 
> pkg/io/io/server/src/drivers/gpio/bcm2835.cc
> pkg/io/io/server/src/drivers/gpio/omap.cc
> 
> And if I am not mistaken, such drivers can be accessed from other components 
> by just doing something like this (testing for validity as we go):
> 
> vbus = l4re_env_get_cap("vbus");
> l4vbus_get_device_by_hid(vbus, 0, &gpio_handle, gpio_hid, 0, 0);
> l4vbus_gpio_set(vbus, gpio_handle, gpio_reg, value);
> 
> It appears that if I just declare the device appropriately in my board's 
> hw_devices.io file, I should be able to get a handle for it using code like 
> the above. And all access can apparently be done via the l4vbus_gpio functions 
> with this handle.

That's not the whole story. Devices declared in e.g. hw_devices.io
describe physical (real) devices and their resources. The device handle
that you obtain via the Vbus API points to a virtual device and only
virtual devices can be assigned to a client's virtual bus. A virtual
device can wrap a physical one but e.g. in the case of GPIOs it can be
composed of individual (or ranges) of physical GPIO resources (= pins).

> (I was also wondering if it was possible to actually instantiate or obtain a 
> device directly instead of obtaining a handle, for code written in C++, but 
> the above is easily good enough at the moment.)
> 
> But now I want to make another, non-GPIO, driver abstraction, instead of 
> directly accessing the mapped memory regions concerned (which I see that some 
> of the drivers do). It seems like I should be able to...

The first question that should be answered is, whether the driver
(abstraction) has to be implemented inside io. Maybe a standalone driver
with an appropriate API is better suited for your use case, because the
Vbus API has its limitations and most likely you need to extend it
anyways. Also from a security standpoint it is maybe worthwile to
implement the driver in its own component.

Currently L4Re is lacking a proper device driver framework and we are
still learning and exploring different directions. Maybe you would like
to discuss your use case further so that we can guide you through that
process?

Regards,
Matthias.

>  * define a class for the abstraction inheriting from Hw::Device
>  * declare the device in hw_devices.io using this class
>  * provide various properties in the hw_devices.io declaration
>    (for configuration purposes)
>  * read the properties in the actual class implementation
>  * access registers in memory just as the GPIO drivers do
> 
> I think I can muddle through all this. But how should another component access 
> methods provided by this driver? Do I have to implement functionality like 
> that provided by the following files...?
> 
> pkg/io/libvbus/lib/src/vbus_gpio.cc
> pkg/io/libvbus/include/vbus_gpio-ops.h
> pkg/io/io/server/src/virt/gpio/vgpio.cc
> 
> Does any of this make any sense? :-)
> 
> I'm just getting started here, but thanks are due in advance for any advice 
> anyone may have!
> 
> Paul