> > I can do a more controlled comparison if you're interested. What would be really useful would be to do some king of automated monitoring of the size of individual parts of the kernel in a few controlled configs. And then as son as somethings grows with > 1% for example then to bring this to lkml. Doing this based on linux-next would allow us to catch the bloaters while they are still or just have been doing certain changes. It would be nice to tell someone that just enabled som new gcc option that this had a cost of 163.432 bytes with a certain config. This would get attraction and be dealt with. Doing so three months later or maybe one year later would often get less focus (if the individual commit ever got identified). Now how to do so I dunno - that would require a bit of tweaking before working reliable. But the value of being quick here would pay of this soon I think. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
