Hi, On Tue, Jun 14, 2011 at 01:48:39PM -0400, Arnaud Lacombe wrote: > On Tue, Jun 14, 2011 at 1:29 PM, Felipe Balbi <balbi@xxxxxx> wrote: > > [...] > > In summary: > > > > We don't want to have library code into their own drivers because, > I am not sure to parse that correctly, could you elaborate ? u_*.c and composite.c are basically library code. We don't want to have composite.ko and/or u_*.ko. > > well, you can only have one gadget driver at a time anyway. And we don't > > want separate compilation due to having stuff out of init sections. > > > on that last point, are you implying that section mapping is not kept > across the different linking steps ? could be. I don't remember all the details. That was back on 2.6.27 times. I would need to really revisit all the details on the archives. What I remember is that Dave noted code shrunk when combining the source files, even if he didn't mark all the other functions as "static". Greg, do you remember why you started this discussion when you first introduced g_utils.ko ?? > ps: about the code size issue, looking at f_acm.c, f_obex.c and > f_serial.c also highlight code duplication... that's USB. While the underlying connection is pretty much the same (serial) between those, the descriptors are completely different and we don't want to have either ifdefs nor phase out descriptors to something else. See those as example implementations for possible real gadget drivers. As of today, we don't have a good solution to avoid that. In fact, a lot of duplication has been removed when the composite gadget framework was introduced. -- balbi
Attachment:
signature.asc
Description: Digital signature
