On Wed, 2005-11-09 at 14:16 -0500, Dave Anderson wrote: > 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? 64k page support is going to be tricky. Atleast 4 level pagetable stuff is default from 2.6.14 onwards. But 64k page support is not default, its a config option. So, we can't base it on kernel version - it should be based on really reading *something* in the kernel to find out if it really is 64k pages and then switch to yet another page table layout :( Thanks, Badari
