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

Attachment: signature.asc
Description: PGP signature

Reply via email to