Linux Device Drivers

Playing Dirty

If you really need a huge buffer of consecutive memory, the easiest (and least flexible, but the least prone to fail) way to allocate it is at boot time. Needless to say, a module can’t allocate memory at boot time; only drivers directly linked to the kernel can play dirty and allocate the memory.

Allocation at boot time looks like the only way to retrieve a big memory buffer, although I’ll introduce an alternative technique (though somewhat worse) in Section 13.3.2, in Chapter 13. Allocating the buffer at boot time is ``dirty'' because it bypasses the kernel’s memory management policies. Moreover, it isn’t feasible for the average user because it involves replacing the whole kernel. Most Linux users are willing to load a module, but are reluctant to patch and recompile the kernel. While I won’t suggest that you use this ``allocation technique,'' it’s worth mentioning because it used to be the only way to allocate a DMA-capable buffer in the first Linux versions, before GFP_DMA was introduced.

But let’s look at how boot-time allocation works. When the kernel is booted, it gains access to all of the physical memory in the system. It then initializes each of its subsystems by calling that subsystem’s initialization function, passing it the current bounds of the free memory area as arguments. Each initialization function can steal part of this area, returning the new lower bound. A driver allocating memory at boot time, therefore, steals consecutive memory from the ...