Date: Sun, 4 Mar 2012 21:32:27 -0800 From: Juli Mallett <juli@clockworksquid.com> To: freebsd-geom@freebsd.org Cc: Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: libgeom's use of kernel pointer identifiers / proper internalization of opaque strings Message-ID: <CACVs6=_aJjmwWSDBL5j1Sx6p=d%2BThLLjK7fKwAJyDLTdU8r=ow@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=_aJjmwWSDBL5j1Sx6p=d%2BThLLjK7fKwAJyDLTdU8r=ow>