Re: Modularizing IOMMUs (devel/iommu-0.4)

["H. Peter Anvin" <hpa@linux.intel.com>]

On 10/20/2010 01:20 PM, Konrad Rzeszutek Wilk wrote:
> Hey Peter, Tomo-san, Jan and Jeremy, and LKML:
> 
> I was wondering if I could run this idea by you guys. One of the things that
> Peter proposed was in some ways to "modularize" the IOMMUs (and potentially
> later on use that framework to "modularize" other built-in components). For details:
> http://lkml.org/lkml/2010/8/2/282 and the follow-on threads.
> 
> If you want to look at code right away, I've some beginnings at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6.git devel/iommu-0.4
> (look at patches past swiotlb-xen: Remove the unnecessary EXPORT_SYMBOL_GPL macros)
> 
> The 10,000 ft view is that during bootup, we want to jettison those IOMMUs
> that are built-in, but actually aren't used b/c the machine does not have it.
> Once it is identified which one we don't want, we mark those sections as available
> for the kernel memory subsystem and we can shed some kilobytes.
> 
> So the first step is to identify the functions for the IOMMUs. And also
> group them tightly together. The path I pursued was to stick all of the
> executable sections in clearly identifiable sections that can be
> easily identified.
> 

I think a much better way to do this is something I discussed with Linus
at least 12 years ago, which is allow modules to be built into the
kernel, but still be unloadable using the actual module mechanism.  This
means they are part of the full kernel image and therefore immediately
available, but appear to the module system as an already-installed
module.  Then we can unload modules to free up space.

This would be a handy thing to have in general, and would simplify this
kind of stuff tremendously.

	-hpa