| Message ID | BANLkTikYqgzZboNB48MnGr87w7w9u6kLMA@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Tue, Jun 14, 2011 at 11:33:32AM -0400, Arnaud Lacombe wrote: > On Tue, Jun 14, 2011 at 3:32 AM, Felipe Balbi <balbi@ti.com> wrote: > > 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@ti.com> 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. > > > What is the problem exactly ? > > The following patch: > > diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile > index 4fe92b1..cc432b8 100644 > --- a/drivers/usb/gadget/Makefile > +++ b/drivers/usb/gadget/Makefile > @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o > # USB gadget drivers > # > g_zero-y := zero.o > +g_zero-y += composite.o > +g_zero-y += usbstring.o > +g_zero-y += config.o > +g_zero-y += epautoconf.o > +g_zero-y += f_sourcesink.o > +g_zero-y += f_loopback.o yes, you can do that. But the problem is the runtime memory footprint that we will have with that. At least that was the reason why Greg had asked Dave to change it to how it is done now. Do we support gcc --combine already ?
On Tue, 14 Jun 2011, Felipe Balbi wrote: > > --- a/drivers/usb/gadget/Makefile > > +++ b/drivers/usb/gadget/Makefile > > @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o > > # USB gadget drivers > > # > > g_zero-y := zero.o > > +g_zero-y += composite.o > > +g_zero-y += usbstring.o > > +g_zero-y += config.o > > +g_zero-y += epautoconf.o > > +g_zero-y += f_sourcesink.o > > +g_zero-y += f_loopback.o > > yes, you can do that. But the problem is the runtime memory footprint > that we will have with that. At least that was the reason why Greg had > asked Dave to change it to how it is done now. What exactly is the runtime memory footprint problem? I thought the whole reason for #include'ing .c files was that back then, the kbuild system wasn't able to do this. > Do we support gcc --combine already ? As far as I know, the only advantage of gcc -combine is that it allows the optimizer to work on more than one file at a time. Would that really make any significant difference for these particular source files? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Jun 14, 2011 at 12:45 PM, Felipe Balbi <balbi@ti.com> wrote: > Hi, > > On Tue, Jun 14, 2011 at 11:33:32AM -0400, Arnaud Lacombe wrote: >> On Tue, Jun 14, 2011 at 3:32 AM, Felipe Balbi <balbi@ti.com> wrote: >> > 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@ti.com> 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. >> > >> What is the problem exactly ? >> >> The following patch: >> >> diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile >> index 4fe92b1..cc432b8 100644 >> --- a/drivers/usb/gadget/Makefile >> +++ b/drivers/usb/gadget/Makefile >> @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o >> # USB gadget drivers >> # >> g_zero-y := zero.o >> +g_zero-y += composite.o >> +g_zero-y += usbstring.o >> +g_zero-y += config.o >> +g_zero-y += epautoconf.o >> +g_zero-y += f_sourcesink.o >> +g_zero-y += f_loopback.o > > yes, you can do that. But the problem is the runtime memory footprint > that we will have with that. At least that was the reason why Greg had > asked Dave to change it to how it is done now. > What number are we talking about ? Using the same hack in `f_loopback.c'[0], here is the numbers I get on x86-64, using gcc 4.5.1, with -O2: combined (C): 14017 1440 288 15745 3d81 drivers/usb/gadget/g_zero.o not combined (P): 13835 1472 296 15603 3cf3 drivers/usb/gadget/g_zero.o the result at -Os is slightly worse: (C) 11318 1344 256 12918 3276 drivers/usb/gadget/g_zero.o (P) 11353 1360 264 12977 32b1 drivers/usb/gadget/g_zero.o - Arnaud [0]: btw, this is a nice source of code duplication, as sourcesink_add() and loopback_add() are pretty much identical. To some extend, f_loopback.c and f_sourcesink.c seem to share very similar code structure... > Do we support gcc --combine already ? > not I know of, but my knowledge are limited. - Arnaud > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Alan Stern wrote: >> Do we support gcc --combine already ? > > As far as I know, the only advantage of gcc -combine is that it allows > the optimizer to work on more than one file at a time. Would that > really make any significant difference for these particular source > files? It should also remove static functions which are not used. However I really don't know the root cause of the memory footprint. Having every file as a separate module might be a little overkill because you need usually ~2 guard pages per module in virtual address space. Maybe a "library" like module. > > Alan Stern > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 14, 2011 at 01:06:16PM -0400, Alan Stern wrote: > On Tue, 14 Jun 2011, Felipe Balbi wrote: > > > > --- a/drivers/usb/gadget/Makefile > > > +++ b/drivers/usb/gadget/Makefile > > > @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o > > > # USB gadget drivers > > > # > > > g_zero-y := zero.o > > > +g_zero-y += composite.o > > > +g_zero-y += usbstring.o > > > +g_zero-y += config.o > > > +g_zero-y += epautoconf.o > > > +g_zero-y += f_sourcesink.o > > > +g_zero-y += f_loopback.o > > > > yes, you can do that. But the problem is the runtime memory footprint > > that we will have with that. At least that was the reason why Greg had > > asked Dave to change it to how it is done now. > > What exactly is the runtime memory footprint problem? I thought the > whole reason for #include'ing .c files was that back then, the kbuild > system wasn't able to do this. not at all. Kbuild has always been able to generate one module from several objects. But then we need to remove "static" from many functions to achieve that. > > Do we support gcc --combine already ? > > As far as I know, the only advantage of gcc -combine is that it allows > the optimizer to work on more than one file at a time. Would that > really make any significant difference for these particular source > files? AFAICT, gcc --combine will really combine the files as if they were one, pretty much the same as including the entire C source. Just look at the rationale from the commit log itself: commit 4e9ba518ec19c6c961bf6074ec05ae1a927230bc Author: David Brownell <dbrownell@users.sourceforge.net> Date: Mon Aug 18 17:41:02 2008 -0700 usb gadget: link fixes for serial gadget Change how the serial gadget driver builds: don't use separate compilation, since it works poorly when key parts are library code (with init sections etc). Instead be as close as we can to "gcc --combine ...". Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> part of it is also in any gadget driver: /* * Kbuild is not very cooperative with respect to linking separately * compiled library objects into one module. So for now we won't use * separate compilation ... ensuring init/exit sections work to shrink * the runtime footprint, and giving us at least some parts of what * a "gcc --combine ... part1.c part2.c part3.c ... " build would. */ you can find all such commits by: $ git log --author="David Brownell" --grep="link fixes" -- drivers/usb/gadget/ And here are the original discussions: http://marc.info/?l=linux-usb&m=121868805717787&w=2 http://marc.info/?l=linux-usb&m=121875765411492&w=2 In summary: We don't want to have library code into their own drivers because, 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.
Hi, On Tue, Jun 14, 2011 at 1:29 PM, Felipe Balbi <balbi@ti.com> 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 ? > 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 ? - Arnaud ps: about the code size issue, looking at f_acm.c, f_obex.c and f_serial.c also highlight code duplication... > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@ti.com> 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.
On Tue, 14 Jun 2011, Felipe Balbi wrote: > On Tue, Jun 14, 2011 at 01:06:16PM -0400, Alan Stern wrote: > > On Tue, 14 Jun 2011, Felipe Balbi wrote: > > > > > > --- a/drivers/usb/gadget/Makefile > > > > +++ b/drivers/usb/gadget/Makefile > > > > @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o > > > > # USB gadget drivers > > > > # > > > > g_zero-y := zero.o > > > > +g_zero-y += composite.o > > > > +g_zero-y += usbstring.o > > > > +g_zero-y += config.o > > > > +g_zero-y += epautoconf.o > > > > +g_zero-y += f_sourcesink.o > > > > +g_zero-y += f_loopback.o > > > > > > yes, you can do that. But the problem is the runtime memory footprint > > > that we will have with that. At least that was the reason why Greg had > > > asked Dave to change it to how it is done now. > > > > What exactly is the runtime memory footprint problem? I thought the > > whole reason for #include'ing .c files was that back then, the kbuild > > system wasn't able to do this. > > not at all. Kbuild has always been able to generate one module from > several objects. But then we need to remove "static" from many > functions to achieve that. If you insist on building an object from multiple source files with separate compilation, the price you pay is making symbols non-static. That's what we have .h files for. And that's also why the [eou]hci-hcd drivers use the same trick of #include'ing various .c files. I really don't know why people object to this idiom. (Note that if the object is a module, non-static symbols don't matter. It's an issue only when the object is linked into the main kernel.) > AFAICT, gcc --combine will really combine the files as if they were one, > pretty much the same as including the entire C source. > > Just look at the rationale from the commit log itself: > > commit 4e9ba518ec19c6c961bf6074ec05ae1a927230bc > Author: David Brownell <dbrownell@users.sourceforge.net> > Date: Mon Aug 18 17:41:02 2008 -0700 Much as I admired David's work, he could sometimes be a little difficult to understand. > usb gadget: link fixes for serial gadget > > Change how the serial gadget driver builds: don't use > separate compilation, since it works poorly when key parts > are library code (with init sections etc). Instead be as "works poorly" how? That is, what goes wrong when you try to use separate compilation? > close as we can to "gcc --combine ...". > > Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > part of it is also in any gadget driver: > > /* > * Kbuild is not very cooperative with respect to linking separately > * compiled library objects into one module. So for now we won't use (I assume this doesn't use the word "library" in a significant sense. It isn't referring to static-link .a library archives, for instance.) In what way is kbuild uncooperative? You said above that kbuild has always been able to build modules from separately-compiled objects. > * separate compilation ... ensuring init/exit sections work to shrink > * the runtime footprint, and giving us at least some parts of what > * a "gcc --combine ... part1.c part2.c part3.c ... " build would. > */ Is the use of init sections the problem? I don't see why it should be. If you link multiple objects into a single module, all the init code should go into a single section. Plenty of drivers throughout the kernel do this successfully. In fact, g_serial did before David's patch, didn't it? > you can find all such commits by: > > $ git log --author="David Brownell" --grep="link fixes" -- drivers/usb/gadget/ > > And here are the original discussions: > > http://marc.info/?l=linux-usb&m=121868805717787&w=2 > http://marc.info/?l=linux-usb&m=121875765411492&w=2 The problem Greg faced was that he tried to put all the library code into a separate module. This clearly leads to potential problems. Suppose module A contains library code in an init section, which is used by the init code in module B. When A is finished loading, its init code is jettisoned. Then when B loads and tries to call that code, the system crashes. It's not clear why single compilation saves space. The difference wasn't tremendous -- in David's g_serial test case (http://marc.info/?l=linux-usb&m=121875765411492&w=2), 42 bytes were saved out of 20000. And the savings was almost entirely in data and bss; you'd have to do some serious digging to figure what really was going on. > In summary: > > We don't want to have library code into their own drivers because, well, > you can only have one gadget driver at a time anyway. That sentence isn't clear. Perhaps you mean that having a single copy of the executable library code at runtime, which could be shared among multiple gadget drivers, doesn't help because there's only one gadget driver present at a time. With the new UDC framework, that won't be true any more. > 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. On the other hand, if you want to share a single copy of the executable library code among multiple gadget drivers, then none of it can go in an init section. Since gadget drivers can be loaded and unloaded at any time, the library code would have to remain in memory permanently -- it couldn't go in an init section. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Jun 14, 2011 at 03:27:47PM -0400, Alan Stern wrote: > On Tue, 14 Jun 2011, Felipe Balbi wrote: > > > On Tue, Jun 14, 2011 at 01:06:16PM -0400, Alan Stern wrote: > > > On Tue, 14 Jun 2011, Felipe Balbi wrote: > > > > > > > > --- a/drivers/usb/gadget/Makefile > > > > > +++ b/drivers/usb/gadget/Makefile > > > > > @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o > > > > > # USB gadget drivers > > > > > # > > > > > g_zero-y := zero.o > > > > > +g_zero-y += composite.o > > > > > +g_zero-y += usbstring.o > > > > > +g_zero-y += config.o > > > > > +g_zero-y += epautoconf.o > > > > > +g_zero-y += f_sourcesink.o > > > > > +g_zero-y += f_loopback.o > > > > > > > > yes, you can do that. But the problem is the runtime memory footprint > > > > that we will have with that. At least that was the reason why Greg had > > > > asked Dave to change it to how it is done now. > > > > > > What exactly is the runtime memory footprint problem? I thought the > > > whole reason for #include'ing .c files was that back then, the kbuild > > > system wasn't able to do this. > > > > not at all. Kbuild has always been able to generate one module from > > several objects. But then we need to remove "static" from many > > functions to achieve that. > > If you insist on building an object from multiple source files with > separate compilation, the price you pay is making symbols non-static. > That's what we have .h files for. And that's also why the [eou]hci-hcd > drivers use the same trick of #include'ing various .c files. I really > don't know why people object to this idiom. (Note that if the object > is a module, non-static symbols don't matter. It's an issue only when > the object is linked into the main kernel.) > > > AFAICT, gcc --combine will really combine the files as if they were one, > > pretty much the same as including the entire C source. > > > > Just look at the rationale from the commit log itself: > > > > commit 4e9ba518ec19c6c961bf6074ec05ae1a927230bc > > Author: David Brownell <dbrownell@users.sourceforge.net> > > Date: Mon Aug 18 17:41:02 2008 -0700 > > Much as I admired David's work, he could sometimes be a little > difficult to understand. > > > usb gadget: link fixes for serial gadget > > > > Change how the serial gadget driver builds: don't use > > separate compilation, since it works poorly when key parts > > are library code (with init sections etc). Instead be as > > "works poorly" how? That is, what goes wrong when you try to use > separate compilation? > > > close as we can to "gcc --combine ...". > > > > Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > part of it is also in any gadget driver: > > > > /* > > * Kbuild is not very cooperative with respect to linking separately > > * compiled library objects into one module. So for now we won't use > > (I assume this doesn't use the word "library" in a significant sense. > It isn't referring to static-link .a library archives, for instance.) > > In what way is kbuild uncooperative? You said above that kbuild has > always been able to build modules from separately-compiled objects. > > > * separate compilation ... ensuring init/exit sections work to shrink > > * the runtime footprint, and giving us at least some parts of what > > * a "gcc --combine ... part1.c part2.c part3.c ... " build would. > > */ > > Is the use of init sections the problem? I don't see why it should > be. If you link multiple objects into a single module, all the init > code should go into a single section. Plenty of drivers throughout the > kernel do this successfully. In fact, g_serial did before David's > patch, didn't it? > > > you can find all such commits by: > > > > $ git log --author="David Brownell" --grep="link fixes" -- drivers/usb/gadget/ > > > > And here are the original discussions: > > > > http://marc.info/?l=linux-usb&m=121868805717787&w=2 > > http://marc.info/?l=linux-usb&m=121875765411492&w=2 > > The problem Greg faced was that he tried to put all the library code > into a separate module. This clearly leads to potential problems. > Suppose module A contains library code in an init section, which is > used by the init code in module B. When A is finished loading, its > init code is jettisoned. Then when B loads and tries to call that > code, the system crashes. > > It's not clear why single compilation saves space. The difference > wasn't tremendous -- in David's g_serial test case > (http://marc.info/?l=linux-usb&m=121875765411492&w=2), 42 bytes were > saved out of 20000. And the savings was almost entirely in data and > bss; you'd have to do some serious digging to figure what really was > going on. > > > In summary: > > > > We don't want to have library code into their own drivers because, well, > > you can only have one gadget driver at a time anyway. > > That sentence isn't clear. Perhaps you mean that having a single copy > of the executable library code at runtime, which could be shared among > multiple gadget drivers, doesn't help because there's only one gadget that's what I meant. > driver present at a time. With the new UDC framework, that won't be > true any more. Good point. > > 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. > On the other hand, if you want to share a single copy of the executable > library code among multiple gadget drivers, then none of it can go in > an init section. Since gadget drivers can be loaded and unloaded at > any time, the library code would have to remain in memory permanently > -- it couldn't go in an init section. very true. Let's leave this alone for now and revisit once all controllers are converted to the ->start()/->stop() methods correctly.
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-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Jun 14, 2011 at 04:01:29PM -0400, Alan Stern wrote: > 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? probably not... But Greg initiated the discussion. It was something related with always recompiling the same objects or something. I really don't recall.
On Tue, Jun 14, 2011 at 09:36:22PM +0300, Felipe Balbi wrote: > 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@ti.com> 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 ?? That was a while ago. I think I was having some build issues with the including of the .c files due to some driver core changes I was working on, so I tried to create that, but then ran into other issues with #defines causing different things to be build in odd ways and breaking the parallel build system. I really can't remember the specifics, sorry. If you can figure a way to clean this up, I would not object to that at all. Sorry I can't be of more help here. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 14, 2011 at 11:16:33PM +0300, Felipe Balbi wrote: > Hi, > > On Tue, Jun 14, 2011 at 04:01:29PM -0400, Alan Stern wrote: > > 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? > > probably not... But Greg initiated the discussion. It was something > related with always recompiling the same objects or something. I really > don't recall. 42 bytes is not worth worrying about :) If it can be merged into a single .ko that the others use, please do it. But for some reason I had problems the last time I tried it, but I can't remember what they were. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 4fe92b1..cc432b8 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o # USB gadget drivers # g_zero-y := zero.o +g_zero-y += composite.o +g_zero-y += usbstring.o +g_zero-y += config.o +g_zero-y += epautoconf.o +g_zero-y += f_sourcesink.o +g_zero-y += f_loopback.o g_audio-y := audio.o g_ether-y := ether.o g_serial-y := serial.o diff --git a/drivers/usb/gadget/zero.c b/drivers/usb/gadget/zero.c index 6d16db9..9e74d8f 100644 --- a/drivers/usb/gadget/zero.c +++ b/drivers/usb/gadget/zero.c @@ -60,23 +60,6 @@ /*-------------------------------------------------------------------------*/ -/* - * Kbuild is not very cooperative with respect to linking separately - * compiled library objects into one module. So for now we won't use - * separate compilation ... ensuring init/exit sections work to shrink - * the runtime footprint, and giving us at least some parts of what - * a "gcc --combine ... part1.c part2.c part3.c ... " build would. - */ -#include "composite.c" -#include "usbstring.c" -#include "config.c" -#include "epautoconf.c" - -#include "f_sourcesink.c" -#include "f_loopback.c" - -/*-------------------------------------------------------------------------*/ - #define DRIVER_VERSION "Cinco de Mayo 2008" static const char longname[] = "Gadget Zero"; build fine for me with CONFIG_USB_ZERO=[ym], beside an obvious visibility issue: diff --git a/drivers/usb/gadget/f_loopback.c b/drivers/usb/gadget/f_loopback.c index b37960f..2300a3d 100644 --- a/drivers/usb/gadget/f_loopback.c +++ b/drivers/usb/gadget/f_loopback.c @@ -372,8 +372,8 @@ int __init loopback_add(struct usb_composite_dev *cdev, bool autoresume) loopback_driver.iConfiguration = id; /* support autoresume for remote wakeup testing */ - if (autoresume) - sourcesink_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP; +// if (autoresume) +// sourcesink_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP; /* support OTG systems */