On Tue, Jun 14, 2011 at 08:28:05AM +0200, Michal Nazarewicz wrote: > On Mon, 13 Jun 2011 17:35:17 +0200, Felipe Balbi <balbi@xxxxxx> wrote: > >We also need to a find a better way to get rid of the inclusion of C > >source files. I understand why Dave did it, but it's been quite some > >time since those patches were committed - e.g. > >7e75bc0f9006e995a0fa25f0a285addc3d5fd5cb - and no progress has been made > >to fix that up. Probably Clang's link-time optimization would help a lot > >on that, but Clang still needs quite some work to be usable for us, so > >we need something else. Any ideas ? > > To me it always seemed like it's a bug in/lack of feature of Kbuild. > Would making Kbuild allow building module from separate .o files be > a problem? maybe the guys at linux-kbuild@vger can help answering this. > Also, at one point in time I had an idea of a framework in which each > individual composite function would be a separate module. I haven't > thought it through though so it's probably not such a great idea after > all. ;) such a framework won't work for Certification. The original composite framework that I implemented with the guidance of Dave was doing exactly that. Each function driver was a module of its own and you built composite gadgets by loading the different drivers. That was until Dave explained to me why it wouldn't fly. You can't have completely dynamic USB peripherals. If you go to certification with something like that, you will be denied certification as your device can change how it appears to the bus at any time. So, the way we have things now, is good. We just need to figure out a way to avoid the inclusion of C files. -- balbi
Attachment:
signature.asc
Description: Digital signature
