On 05/19/11 08:49 AM, Bill Sommerfeld wrote:
On 05/18/11 10:32, Darren J Moffat wrote:
So no you aren't supposed to be able to write 3rd party tools and link
them against the libzfs API.
That's quite a bit stronger than I'd put it and also too discouraging.
libzfs is a private interface. Private does not mean "secret".
Private interfaces can change incompatibly at any time -- even in a
patch. They're not guaranteed to keep working when the underlying
shared library changes interface or behavior -- a function you depend on
may be deleted, or grow another argument, or just change behavior in a
way you weren't expecting.
If you find that the path of least resistance is to use a private
interface, it's often a sign that there's a missing Public interface in
the system.
I think there is a case for a public interface for a subset of the
libzfs API, the functionality provided is too useful to hide away form
application programmers.
I must confess that I do use the interface in a number of my tools and I
use compile time (and conditional compilation) assertions based on
SPA_VERSION to force me to review the code when the version changes.
This my not be safe, or even a good idea but it has kept me out of
trouble since version 15. When I first started playing way back when
libzfs first appeared, I hadn't cottoned on to the interface being private.
Some very useful interfaces have remained stable throughout and these
would good candidates for a public API. Even just providing the ability
to open a pool or dataset, read its properties and iterate its children
would be extremely valuable for those of us who live in user space.
This only requires a small set from the full API:
libzfs_init(), libzfs_fini(), zfs_open(), zfs_close(), zfs_get_xxx(),
zfs_prop_get_xxx() and zfs_iter_xxx().
All of these have been stable a long while and given their simple roles,
should remain so.
--
Ian.
_______________________________________________
zfs-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/zfs-code
