On Mon, Feb 24, 2025 at 11:57:47AM +0000, Aditya Garg wrote: > > On 24 Feb 2025, at 5:13 PM, andriy.shevchenko@xxxxxxxxxxxxxxx wrote: > > On Mon, Feb 24, 2025 at 11:20:12AM +0000, Aditya Garg wrote: > >> > >>> It would be nice to see the difference in the code generation for the all > >>> __packed vs. only those that require it. > >>> > >>>> At least it's clear then > >>>> what happens. And if your hardware requires this, you can't do much anyway. > >>> > >>> One aspect (member level alignment) is clear but the other is not > >>> (object level alignment). I dunno if it makes sense to be pedantic about this, > >>> but would like to see the binary outcome asked for. > >> > >> Hex dump of the compiled binary: > > > > Oh, sorry I wasn't clear. We have a script called bloat-o-meter for these > > purposes. Please, run it with old and new binaries as parameters and share the > > output. > aditya@MacBook:~/linux$ ./scripts/bloat-o-meter $PACKED $UNPACKED > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > Function old new delta > Total: Before=13286, After=13286, chg +0.00% Thanks! That shows that __packed can be used for all protocol related data types. Just mention in the commit message that the __packed, even if not needed, is: a) for the consistency, b) not affecting code generation in accordance with bloat-o-meter. -- With Best Regards, Andy Shevchenko
