On Wednesday, January 30, 2013 02:29:04 PM Eric W. Biederman wrote: > "H. Peter Anvin" <hpa at zytor.com> writes: > > On 01/30/2013 01:57 PM, Eric W. Biederman wrote: > >>> Yes, those seem to be the options, and we're currently discussing which > >>> one. > >>> > >>> The second seems to make more sense to me. The kexec tools build the > >>> memory map anyway, and it makes sense to me at least to just build a > >>> memory map with the appropriate regions marked as a dumpable type. > >> > >> This dumpable type doesn't make sense to me. Are you suggesting making > >> regions that are memory but that we should not use a special memory > >> type? > > > > Yes. > > > >> I think I would prefer that to call that new type RESERVED_MEM or > >> RESERVED_CACHABLE. Being more specific is fine but dumpable certainly > >> doesn't bring to mind what we are saying. Especially since we already > >> communicate which areas were memory to the last kernel in an > >> architecture generic format. > > > > I was thinking that marking them differently might help debugging, at > > least, but yes, we can have a RESERVED_MEM type. > > > > However, Thomas does have a point that the current use of fairly small > > positive values for Linux-defined types is a bad idea. We should use > > negative types, or at least something north of 0x40000000 or so. > > Yes. It doesn't much matter in the kernel but when it because part of > the ABI it is a real issue. That's one point (self made up e820 type should better be kept kernel internal). > Since old kernels treat any value they don't understand as reserved > passing a modified e820 map seems reasonable to me once we have reserved > a special linux value for it. The other one: Why should several instances modify the e820 table if this is not necessary? I guess both ways are a huge enhancement compared to what we have now. Which approach to finally take should not matter that much, but because of above I still prefer to go this way: - Pass a kernel command line option that just changes the kernels idea of which memory it can touch Whether the value(s) of these types should be ramped up is a different discussion then. If they still should have bigger values, this can be addressed by a separate patch now or later to whatever you like to see. Thomas
