On Tue, 14 Jun 2011, Felipe Balbi wrote: > > > And we don't want > > > separate compilation due to having stuff out of init sections. > > > > I still don't understand what the issue is with that. There are plenty > > of driver modules built from multiple, separately-compiled objects > > that use init sections without trouble. > > Maybe we should turn u_*.c and composite.c into their own modules now > that we're starting to allow multiple gadget controllers and thus > multiple gadget drivers loaded. I failed to see that, great catch. That's not what I meant. I was asking for an explanation of your statement: And we don't want separate compilation due to having stuff out of init sections. Why should separate compilation force you to move stuff out of init sections? Consider usbcore as an example. Grepping through drivers/usb/core/*.c, you'll see there are init routines in devio.c, inode.c, and usb.c. These files are all compiled separately. Yet they are linked into a single object module, usbcore.ko, and the init sections work out just fine. In short, I don't see what's wrong with separate compilation. Apparently the only problem David found was that it increased the size of the final driver by 42 bytes. Is that really worth worrying about? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
