Felix Fietkau
2018-Apr-05 13:27 UTC
[Bridge] [PATCH 00/12] Ethernet: Add and use ether_<type>_addr globals
On 2018-03-31 09:05, Joe Perches wrote:> There are many local static and non-static arrays that are used for > Ethernet broadcast address output or comparison. > > Centralize the array into a single separate file and remove the local > arrays.I suspect that for many targets and configurations, the local arrays might actually be smaller than exporting a global. You have to factor in not just the .text size, but the fact that referencing an exported symbol needs a .reloc entry as well, which also eats up some space (at least when the code is being built as module). In my opinion, your series probably causes more bloat in common configurations instead of reducing it. You're also touching several places that could easily use eth_broadcast_addr and eth_zero_addr. I think making those changes would be more productive than what you did in this series. - Felix
Joe Perches
2018-Apr-05 13:51 UTC
[Bridge] [PATCH 00/12] Ethernet: Add and use ether_<type>_addr globals
On Thu, 2018-04-05 at 15:27 +0200, Felix Fietkau wrote:> On 2018-03-31 09:05, Joe Perches wrote: > > There are many local static and non-static arrays that are used for > > Ethernet broadcast address output or comparison. > > > > Centralize the array into a single separate file and remove the local > > arrays. > > I suspect that for many targets and configurations, the local arrays > might actually be smaller than exporting a global.I tried x86-64 allnoconfig and defconfig. Those both did not increase vmlinux size. The defconfig actually got smaller, but that might have been some object alignment oddity.> You have to factor in > not just the .text size, but the fact that referencing an exported > symbol needs a .reloc entry as well, which also eats up some space (at > least when the code is being built as module).Thanks, the modules I built got smaller.> In my opinion, your series probably causes more bloat in common > configurations instead of reducing it. > > You're also touching several places that could easily use > eth_broadcast_addr and eth_zero_addr. I think making those changes would > be more productive than what you did in this series.Doubtful. AFAIK: possible unaligned addresses.