| Message ID | cover.1522479607.git.joe@perches.com |
|---|---|
| Headers | show |
| Series | Ethernet: Add and use ether_<type>_addr globals | expand |
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
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.
On 2018-04-05 15:51, Joe Perches wrote: >> 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. Please post some numbers to show this. By the way, on other architectures the numbers will probably be different, especially on ARM/MIPS. >> 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. Those two are just memset calls, alignment does not matter. - Felix