Hi Andy, On Tue, 5 Oct 2021 at 21:14, Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > Ok, is there a reason it's not for the ID tables? Does it break something? > > It will look ugly. Why we define a table that may or may not be used? > Sounds fishy. I guess it's a toss up between is the attribute more ugly than #ifdefs and is the ugliness of either worth it.. Not going to say I have an answer here. :) > On top of that why you should tell linker to waste resources on something > that you may well know beforehand will be thrown away? That's true but the linker on my machine with 64GB of RAM compiling for a single core machine with 64MB of RAM doesn't mind too much. > > For what it's worth I think the OF ids are a bit wasteful. > > Exactly my point, but fixing one driver of zillions does not solve the issue > in general. I looked into making OF ids smaller globally. There seems to be 64 bytes wasted from the start for the name and type fields as nothing uses them as far as I can tell. Then you have the array for the compatible string which is currently 128 bytes but the longest compatible string in the kernel is less than 64 from what I can tell. I understand that it's for future proofing etc. Adding a few hacks to my kernel to remove the unused fields and reduce the size of the compatible string saved a few tens of K. Which isn't a lot but might be the difference between the kernel fitting in a tiny SPI NOR partition or not. > > For some > > drivers where there are tons of broken variations they add a few K of > > unneeded data. But since everyone now has gigabytes of memory I doubt > > they care... > Some actually cares. > Ok.. I might consider pushing my changes to remove unused ids all over the place then. drivers/cpufreq/cpufreq-dt-platdev.c is a really good example of adding ~10K to kernels for no reason. > > I'm working with 64MB. :) > > Then I would imagine that you already using as less kernel configuration as > possible and have as many modules as you want for the hardware that might > appear to be connected to that board, right? I have a minimal config but compiling in macb for the ethernet compiles in code and ids for stuff like zynq that I could do without. >Then again one driver with 100+ > bytes doesn't affect really your case. Disabling, for example PRINTK, will > win much more for you. It's not *that* bad just yet. :) Anyhow, thankyou for the interesting discussion. I'll just leave this in my tree for now so I don't have to see the warning. Cheers, Daniel
