Hi Alexander,
excellent that you got the driver working. Congratulations! :-)
For now, I'll finish porting ethernet or rndis usb gadget and prepare the patches for the dde kit. Currently I would like to make usb otg a separate service inside the usb_drv (just as nic and input) for simplicity, but I would like to hear your opinion on how we should rework the makefile and dde_linux to make it possible to build drivers into separate binaries.
Merging the new driver into the existing usb_drv is a pragmatic starting point to reach a working state - just as you did. However, before incorporating these changes into mainline, I would like to see the otg driver to become a separate component that is independent from the usb driver. It is easy to add to existing code but it is hard to cut back code from the emulation environment once added. By adding the otg driver to the usb_drv, we would have a hard time to split those two drivers into two pieces (while aiming at having a minimal-complexity 'lx_emul.h' for each of them) at a later time.
I would suggest to create a new target at 'dde_linux/src/drivers/otg/target.mk' by taking the 'usb/target.mk' as blue print and removing all the parts that are not needed for otg. Based on your current version of 'lx_emul.h' (that contains the emulation environment for the combined usb+otg driver), the next step would be to minimize the emulation environment. When having reached a state where nothing can be removed, we can look for common parts between 'drivers/otg/lx_emul.h' and 'drivers/usb/lx_emul.h'. For each reasonably large block of common code, I would create a file 'drivers/lx_emul_<module>.h', which can then be included by both 'usb/lx_emul.h' and 'otg/lx_emul.h'. For example, the common (but only the common) types will go to 'lx_emul_types.h'. Maybe, we could use the name of the corresponding linux kernel headers as the <module> name?
As we proceed, we will get a nice library of 'lx_emul_*.h' snippets that can be easily reused to construct driver-specific emulation environments.
The 'target.mk' files will certainly have duplicated parts. Those parts should go to a common 'target.inc' file.
Also, in future it would be nice to add more granularity to the platform code in dde_kit as well as in other genode services because eventually we'll have to think of how to keep multiple boards with the same SoC in one tree.
As of now, 'dde_kit' is pretty platform agnostic. Where do you see the need for platform-specific additions to 'dde_kit'?
One thing we've found is that the at the header preprocessing stage genode makefile fails on the "musb_regs.file" at the following line: #include "tusb6010.h" /* Needed "only" for TUSB_EP0_CONF */ It is confused by the quotes there. If we remove them, it works fine. If we do not, a strace shows that an emtpy line appears somewhere, as if the opening quotation mark terminates a string somewhere in the preprocessing stage.
Thanks for reporting. This is a problem with the regular expression used in 'drivers/usb/target.mk' at line 56:
https://github.com/genodelabs/genode/blob/master/dde_linux/src/drivers/usb/t...
Does it work when changing the expression to the following (replacing '.*' by '[^>"]')?
"s/^#include *[<"]([^>"]*)[>"].*/\1/"
Btw, I've found some time to write down my thoughts about what I want to see in genode one day, but it had boiled down to what's being discussed here lately - power management and graceful service restart on errors (http://t.co/14KBWz7X)
I enjoyed your article and also your other rants. ;-) Thanks for the nice words about Genode! I think that your observations about the current shortcomings are spot-on. Each of the points would deserve attention. I suggest to discuss each of them separately. The question is how to prioritize those points among the many other current construction sites of the project?
When reading the part about languages, I got the impression that you would really appreciate the D programming language. Have you had a look into it?
Cheers Norman