15:25:03 <gitomat> [illumos-gate] 15887 truss can fail to update data_model -- Keith M Wesolowski <wesolows⊙oc>
20:07:41 <danmcd> Anyone here know the email of any FreeBSD BHYVE folks (e.g. Michael Dexter)?
20:07:48 <danmcd> Please DM me if you know.
20:22:15 <danmcd> All set, thanks.
22:25:04 <jbk> rmustacc: any drawbacks to keeping around a topo handle for the lifetime of a process (and just calling topo_snap_hold() / get_data / topo_snap_rele() as needed to get topo data?
22:25:33 <jbk> i haven't found any guidance (since it's all undocumented), so not sure if I should do that, or also open/close anytime i need to refresh some topo data
22:25:59 <richlowe> the obvious thing to check would be what data associated with the handle stays alive
22:26:58 <richlowe> but I was pretty sure fmd kept it alive?
22:27:48 <richlowe> seems to keep it alive and refcount it
22:28:41 <jbk> looking at topo_open(), for the most part, it seems ok to do that, but it does a topo_builtin_create() which does topo_mod_enumerate()
22:28:45 <richlowe> wait, no I got confused about something
22:28:57 <richlowe> it looks to re-open it in fmd_topo_update()
22:28:58 <jbk> which is where I'm wondering if that might present issues
22:29:59 <richlowe> so it looks like fmd does a new topo_open() each fmd_topo_update() and then refcounts it as consumers (there) will outlive that function.
22:30:12 <richlowe> which is why I got confused
22:30:49 <richlowe> it looks hooked in to only update the topo on DR events though.
22:31:07 <richlowe> and I would assume, absent complaints from fishworkers, that fmd is the canonical long-lived consumer
22:31:17 <richlowe> so doing what it does would make sense to me