On Wed, 10 Mar 2010 13:15:25 +0100 Marco Stornelli <marco.stornelli@xxxxxxxxx> wrote: > 2010/3/10 Yuasa Yoichi <yuasa@xxxxxxxxxxxxxx>: > > 2010/3/10 Marco Stornelli <marco.stornelli@xxxxxxxxx>: > >> 2010/3/10 Yuasa Yoichi <yuasa@xxxxxxxxxxxxxx>: > >>> Hi, > >>> > >>> 2010/3/10 Marco Stornelli <marco.stornelli@xxxxxxxxx>: > >>>> Ramoops, like mtdoops, can log oops/panic information but in RAM. > >>> > >>> What is different from mtdoops + mtd-ram? > >>> > >>> Yoichi > >>> > >> > >> It can be used in a very easy way with persistent RAM for systems > >> without flash support. For this systems, with this driver, it's no > >> more needed add to the kernel the mtd subsystem with advantage in > >> footprint as I said in the description. > > > > right. > > But, > > > >> In addition, you can save > >> flash space and store this information only in RAM. I think it's very > >> useful for embedded systems. > > > > CONFIG_MTD_RAM uses only RAM. > > I think there's no big difference about this point. > > > > I meant with the "classic" use of mtdoops, therefore with a flash > partition without use MTD_RAM. Using MTD_RAM, it's more or less the > same thing, with the exception of "where" you want deploy the log. For > example: if in your system you have got a nvram you can use it without > problem, you need to specify the address of the nvram to the module. > Very simple. I think it's a small driver but very useful, feedback > from other embedded guys are welcome. Seems sensible to me. If you have a machine whose memory is persistent across reboots then you reserve an arbitrary 4k hunk of memory for collecting oops traces, yes? What tools are used for displaying that memory on the next boot? How do those tools distinguish between "valid oops trace" and "garbage because it was just powered on"? A magic signature? Should the kernel provide the 4k of memory rather than (or in addition to) requiring that the system administrator reserve it and tell the kernel about it? That'd be a matter of creating a linker section which isn't cleared out by the startup code. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
