On Sun, May 31, 2026 at 11:44 AM Richard Henderson <
[email protected]> wrote:
> On 5/30/26 21:36, Warner Losh wrote:
> > + for (int i = 0; i < n; ++i) {
> > + struct kinfo_vmentry *k = &entries[i];
> > + size_t path_len = strnlen(k->kve_path, sizeof(k->kve_path))
> + 1;
> >
> >
> > This is shorter than what I had in blitz.
>
> Shorter, but wrong, since it's never 0.
>
True.
> >
> > + MapInfo *e = g_malloc0(sizeof(*e) + path_len);
> >
> >
> > My version did the following only if
> > if (kve->kve_type != KVME_TYPE_GUARD &&
> > kve->kve_type != KVME_TYPE_DEAD) {
> >
> > though now I see my version would have been better with the
> > contrapositive and continue.
>
> You wouldn't want to skip GUARD, since for the purpose of probe_guest_base
> GUARD is
> reserved memory. What does DEAD mean? Is that the multithreaded thing?
>
I don't know what I was thinking for either of those, now that I refresh my
memory
on what they are. GUARD works coincidentally because the regions are small
and
none would be selected... DEAD can likely never happen in userland, since
it's only
for objects that are dying and in the process of being deallocated, but not
yet
unreferenced... I'm not sure how this could arise when this function is
being called,
though, so I guess my difference isn't any better at all.
> > + free(entries);
> >
> >
> > I had g_free() here, but I am a 'cargo cult' glib user...
>
> I know they're the same these days, but I minded the man page which says
> 'free'.
>
Oh! The sysctl method vs the kinfo_getvmmap method. Yes, this is right. I'd
malloced
memory for mine with g_malloc...
> > +
> > +if host_os == 'freebsd'
> > + libutil = cc.find_library('util', required: true)
> > + user_ss.add(libutil)
> > +endif
> >
> >
> > This dependency is likely fine, but as I said in my other mail using the
> sysctl obviates
> > the need for this.
>
> I'm fine either way. Perhaps this isn't worth pulling in the external
> dependency.
>
Same.
> > And thank you so much for writing this, even though there's a small
> collision here. I do
> > very much appreciate it.
>
> You're welcome.
>
>
> r~
>
