Trouble porting linux driver to DDE Kit

[Norman Feske]

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/target.mk

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth