|Summary:||Userland support for libzfs and libzfs_core feature request|
|Product:||Base System||Reporter:||Sean Sill <sms3h2>|
|Component:||kern||Assignee:||freebsd-fs (Nobody) <fs>|
|Severity:||Affects Some People||CC:||asomers, maciej, msl0000023508|
Description Sean Sill 2014-09-18 14:04:44 UTC
Currently to compile against libzfs, or libzfs_core you need to have the entire kernel source available. Compiling against it is also a pain as many kernel only types seem to "leak" through or are present and shouldn't have to be. There should be a port for zfs-devel or something similar with the required headers need to link compile against libzfs, or libzfs_core.
Comment 1 WHR 2021-09-09 04:13:05 UTC
Link to #257222.
Comment 3 Alan Somers 2021-09-09 04:39:42 UTC
The thing about libzfs is that it is not a stable interface. It was never intended to be one, and never has been. It changes frequently, and in non-backwards compatible ways. That's why its use is highly discouraged by programs outside of the base system. The few that do use it (sysutils/py-iocage for example) typically break during an OS upgrade. libzfs_core, OTOH, _is_ a stable interface. It has a simple API, very similar to what the zfs command line tools provide. And it's guaranteed to preserve backwards compatibility. FreeBSD 13+ include libzfs_core.h in /usr/include, and libzfs_core is finally mature enough that you can write useful applications with it. So I think this bug is finally resolved.