Hi Alexander,
But if we use string names to identify pins and integers for configuration, like it's currently implemented in linux and like I've done for Genode, we can probably have the unified interface for all SoCs. I would suggest keeping the PINMUX separate from GPIO at least until we add the support for 2-3 SoCs
I would like not to use strings but enum values in Genode's session interfaces because this way, the compiler will safe us from spelling mistakes. The values could be defined in SoC-specific headers, which can be included by the generic interface. Do you think this is reasonable?
Resource arbitration is another interesting topic. Various resources such as GPIOs, regulators, clocks and even memory regions should be somehow assigned capabilities in a coarse-grained manner. For that I would like to know if there is or is planned a simpler way than writing a proxy limiting access to a subset of resources for each session type, or this could be somehow automated.
There are two approaches. The easiest one is letting the driver enforce session-specific policies (take a look at nitpicker or ram_fs for examples of employing this scheme). In short, the parent of the driver supplies a configuration to the driver, which expresses the policy imposed to different sessions. This scheme turned out to be useful in many cases. For example, when Ivan extended the nic_bridge for static IP addresses, he used this approach.
The other way would be the "proxy" approach where the session creation is monitored by a component that imposes policy. For example, a vpci server may present virtual PCI busses to different clients and use the pci_drv as back end.
For a start, I would suggest (and try doing) simply porting the drivers
from linux and having a simple interface like looking up resources
If you are planning to port drivers from Linux, I would like to encourage you to follow the lines of the drivers in 'dde_linux'. This has two reasons. First, the used methodology is a clean way to port drivers without "hacking" them. So we can keep the driver up to date by upgrading the Linux version of 'dde_linux'. Second, we cannot incorporate 3rd-party GPL code into Genode's base system (which includes the 'os' repository). This would prevent Genode Labs from licensing Genode under non-GPL terms. So Linux code must stay within 'dde_linux' only.
I'm currently in the process of writing an article about my concerns about Genode, I plan to finish it by the weekend and would like you to comment on some points. It will probably be posted somewhere at the Ksys website
Very good. I'm looking forward to your article.
Cheers Norman