On Tue, Feb 05, 2019 at 09:14:46AM -0800, John Baldwin wrote: > On 2/5/19 8:25 AM, Bruce Evans wrote: > > On Tue, 5 Feb 2019, Ed Maste wrote: > > > >> On Tue, 5 Feb 2019 at 05:17, Bruce Evans <b...@optusnet.com.au> wrote: > >>> > >>> On Mon, 4 Feb 2019, Ed Maste wrote: > >>>> This should probably be uin64_t to support cross-debugging cores from > >>>> 64-bit machines on 32-bit hosts; also for i386 PAE. Or, on IRC jhb > >>>> suggested we introduce a kpaddr_t typedef akin to kvaddr_t. > >>> > >>> The correct type is vm_paddr_t or maybe a kvm wrapper of this. > >> > >> That precludes cross-arch and cross-size use of kvm_walk_pages; kvm > >> supports this use (see kvm_read2) so it should be a 64-bit kvm > >> wrapper. > > > > kvm or system? kvaddr_t is system and the corresponding physical address > > type should probably be system too. > > It only needs to exist for libkvm. I want to make a 'portable' libkvm that > can be built on non-FreeBSD OS's such as OS X, etc. That is the last thing > needed to let kgdb run on non-FreeBSD OS's to cross-debug crash dumps. For > that you would want self-contained types I think such as kvm_vaddr_t and > kvm_paddr_t. I guess I just reused kvaddr_t because it already existed, > but having dedicated types in kvm.h is probably better long term.
IIRC, you created kvaddr_t first and I co-opted it for the kernel after finding a namespace collision when I merged the kvaddr_t from CheriBSD. Using kvm_ types seems like a good idea for the reaons you hilight. -- Brooks
signature.asc
Description: PGP signature