Kernel pointer values are used as opaque unique identifiers, which are then
used to reconstruct references between various providers, classes, etc., inside
libgeom from the source XML. Unfortunately, they're converted to pointer-width
integers (in the form of pointers) to do this, and 32-bit userland pointers
cannot hold sensible representations (however opaque) of 64-bit kernel pointers
on all systems.
In the case where the leading bits are zero and 32 distinct bits of pointer can
be identified, this will happen to work. On systems where the upper 32-bits of
kernel pointers are non-zero and the same for all kernel pointers, this will
result in double frees and all kinds of bizarre crashes and linkage between
objects inside libgeom.
To mitigate this problem, treat the opaque identifiers in the XML as C strings
instead, and internalize them to give unique and consistent per-object pointer
values in userland for each identifier in the XML. This allows us to keep the
libgeom logic the same with only minor changes to initial setup and parsing.
It might be more sensible for speed reasons to treat the identifiers as numbers
of a large size (uintmax_t, say) rather than strings, but strings seem fine for
now.
(As an added side-effect, this makes it slightly easier to identify unresolved
references, but nothing has been added to inform the user of those.)
3dce589cb9