Re: [PATCH 04/11] persistent_ram: Introduce persistent_ram_new()

[Anton Vorontsov]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/