Hi! > This patch is the result from the following discussion. > > http://thread.gmane.org/gmane.linux.ide/16475 > > The problem is that CONFIG_PM affects a lot of low level drivers and > scattering CONFIG_PM all over the place is too ugly. This patch... > > * implements __attribute_discard_text__ and __attribute_discard_data__ > (not implemented for modules yet, only for built-ins) > * uses them to implement __pm and __pmdata markers > * convert libata midlayer and ahci to use it instead of CONFIG_PM > > __attribute_discard_text/data__ puts the marked symbols in separate > sections which are located from VMA 0 and discarded when generating > the final image. It's similar to putting those into /DISCARD/ section > but won't complain even if the discarded symbols are referenced by > active sections. As the discard sections are located from VMA 0, > actually dereferencing such symbols will result in OOPS. > > This trick certainly makes LLDs cleaner but there are also some > downsides, so here are the cons. > > * Cannot depend on the compiler to detect illegal dereferences to > discarded symbols. We probably can do this using sparse. > > * Cannot use the compiler to detect unused but unmarked symbols. This > also probably can be done with sparse. > > * EXPORT_SYMBOL() is nullified, so it will take extra bytes for > each symbol marked with __pm. (insignificant) > > * Implementation involves modifying kernel image, module build process > and possibly sparse. It might be too expensive to achieve device > driver prettiness, but there are a lot of device drivers out there > and a lot of CONFIG_PM's to be added. Also, discard attributes can > be used for other purposes too. > > Any better ideas? Comments? Seems ok to me. Certainly better than config_pm... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
