libgeom's use of kernel pointer identifiers / proper internalization of opaque strings

[Juli Mallett]

Hello again,

I haven't gotten any feedback on this problem in the last 10 days and
at this point think the path I took is the best one forward at this
time.  It's my plan to commit in the near future (within a few days, I
suppose) unless anyone has an objection.  If anyone wants to give it a
review or if multiple people decide to test it on their systems, I'd
be happy to commit earlier.

Thanks,
Juli.

On Sun, Mar 4, 2012 at 21:32, Juli Mallett <juli at clockworksquid.com> wrote:
> Hey folks,
>
> libgeom assumes that the id and ref parameters from the kernel can be
> represented as userland pointers.  This is certainly handy in terms of
> making the pointer substitution that occurs straightforward, but it
> breaks running a 32-bit libgeom on a 64-bit kernel where the first
> 32-bits of the kernel pointers are identical and non-zero.  It seems
> to me that using strtoumax and uintmax_t for the opaque identifiers
> and making the pointers separate fields will give better behavior in
> general (no crashes on unresolved references in the kernel due to
> someone forgetting to properly declare a class) and also fix this
> problem.
>
> If that is undesirable, then using gident to do internalization on the
> fly either using strtoumax or using the strings directly might be
> better.  Here's a rough cut of using the strings to do internalization
> which I've tested and believe can be committed.  If anyone feels like
> reviewing it or suggesting a better fix to libgeom, I'd be happy to
> hear it.
>
> http://people.freebsd.org/~jmallett/internalize-libgeom-ids.diff
>
> CCing Nathan W. who does not see this problem on PowerPC64, but I
> suspect could under the right circumstances.
>
> Thanks,
> Juli.
>
> PS: Please CC me as I am not subscribed to the list.  And if you think
> the patch is great, just commit me.  I don't really want to touch
> libgeom.