Badari Pulavarty wrote: > > > > It's kind of a chicken-and-egg situation, where the first readmem() > > needs the virtual address range stuff to be in place, but we need > > something out of the kernel data space to determine the virtual > > address space range data. That being said, it looks possible, at > > least in the case of ppc64, that perhaps we could get away with > > doing a readmem() of a unity-mapped address, since at the > > point where the VM-range decision is made, machdep->kvbase > > has just been set. (Follow the readmem() path, and you'll see > > what I mean...) But you'd have to read raw data and muck > > your way through it because the embedded gdb hasn't been > > invoked yet. Badari had asked the same thing earlier, about > > using the THIS_KERNEL_VERSION macro, but again, the > > underlying crash data to satisfy the macro doesn't get initialized > > until after gdb is alive. > > Okay. It looks like we can delay deciding 4-level pagetable layout > till POST_GDB stage. Since THIS_KERNEL_VERSION is set by then, I was > able to use that instead :) Ok -- sorry, I'm so far behind in my mail, I answered your last query before I got to this one. So doing it this late should be OK -- as long as there never becomes a requirement to access a vmalloc address data prior to that point. One question -- if the 64k page support is put in place for 2.6.14, are you going to run into the same kind of "qualification" issue? Dave
