Hello Colin, On Mon, May 14, 2012 at 05:37:56PM -0700, Colin Cross wrote: [...] > even worse, mem= from the bootloader. Mixing the two methods together > would be confusing. Yes, mixing is discouraged. The mem= hack is mostly useful for developers, for hacking random kernels. Even on x86 it is useful, when you want to grab an oops, but you don't have say netconsole, or HW really screwed up and you don't have any means to get the oops log, ramoops may become quite useful. But in the Android phone scenario, if you want to have this feature into production kernels, platforms should register the ramoops platform driver, as they were doing before. > Either persistent_ram_early_init should be > removed completely (or replaced with something that is easier to > register ramoops into), or ramoops should use > persistent_ram_init_ringbuffer like ram_console does. Yep, this was indeed my original idea: persistent_ram_early_init should go. Boards (or generic arch/ or arch/mach-* code that knows memory layout) will have to just do two things: 1. Wisely and early call memblock_reserve(). 2. Register a ramoops platform device pointing to the reserved memory. This is actually exactly the same as you were doing with ram_console: 1. Platform were adding an entry to the global list of persistent ram zones, and then were calling persistent_ram_early_init() somewhere in the arch/ code (at least that's how I understood the idea of the code, as there are currently no in-tree users). 2. Then platforms were registering a ram_console platform device, and the driver would find out the needed zone by matching on the device name. Thinking about it, the whole thing was actually abusing the device-driver model a little bit. So things are just easier now. Thanks! -- Anton Vorontsov Email: cbouatmailru@xxxxxxxxx _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
