On Wed, 22 Dec 2010 10:28:41 -0800 Tony Lindgren <t...@atomide.com> wrote:
> > Nice to see that the idea is welcome. Did you had a look at the > > implementation in patch 1/6 ? > > No not yet, will take a look after we're done with this upcoming > merge window.. Great, thanks. > Ideally the new sections would be arch/arm generic sections and not > omap specific. I could see ARMv6 and ARMv7 sections being one way > to group them, but that does not help to drop omap3 specific data > on omap4. The mechanism is architecture independent, not OMAP-specific or even ARM-specific (the only architecture-dependent part is the modification of the kernel linker script, but it's trivial to adapt to other arches). You can put as many sections as you want, you just need to declare some macros: #define __something_data cond_data_section(something) #define __something_text cond_text_section(something) and then mark whatever you want with __something_data or __something_text. It will then be part of separate sections, that are page-aligned so that they can independently be freed. For the moment, the API allows to tell which sections you want to *free*, but I think I should turn it into an API that allows to tell which sections you want to *keep*. This way, if you have sections for 100 machines and you boot on a given machine, you only need to say "I'm using this section". At the end of the kernel boot process, all sections that have not been marked as useful would be removed. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
