Couple of questions about this: What are the expected benefits over fork/exec'ing the zpool/zfs commands?
There are a lot of things happening in zfs_main.c and zpool_main.c. How much of that are you suggesting move to the new library? E.g. we could be talking about an API like `int run_zfs_command(char *argv[])` that essentially invokes main(). But having that library print to stdout, etc might not be what you're looking for. How would you want errors to be expressed in the new API? Maybe you could give some examples of subcommands that do not have good equivalents in libzfs. Here are a few that I looked at: zfs_do_set(): it seems to me that zfs_prop_set_list() is a good libzfs interface to use in its place. But maybe you have something different in mind? zfs_do_send(): its CLI parsing is much more complicated but it looks like it boils down to one call to zfs_send_*(). Are you thinking that we should make a single API entry point that would cover all the zfs_send_*() variants? zfs_do_list(): the logic in print_dataset() is a little involved, but unless you want the library to be generating the same string output that we have from the CLI, it seems like the existing libzfs functions for examining the zfs_handle_t seem decent. Again, maybe an example of what you would like to see for a "true" API that's equivalent to zfs_do_list() would be helpful. --matt On Mon, Mar 2, 2020 at 8:53 AM Mike Carlin via openzfs-developer < developer@lists.open-zfs.org> wrote: > Dear OpenZFS, > > Within various applications that make use of ZFS, the means of integration > is largely done by calling the zfs/zpool/etc. executables and parsing the > output (e.g. moby, lumina). I'd like to see an additional path for > integration in the form of an API that provides equivalent functionality to > the CLI. While it's true that libzfs and libzfs_core expose all the > building blocks necessary to achieve the same result as the aforementioned > executables, there's a fair amount of logic in the executables that would > need to be duplicated to provide equivalent functionality. > > I propose that a separate library (or possibly header/source in libzfs) be > created, using the logic present in zpool and zfs to provide the same > functionality exposed as an API. A few benefits from this: > - Allow for an alternate and potentially better integration path for third > party applications > - Simplify zpool and zfs to really just focus on CLI related concerns > > In my view, the "true" API to OpenZFS is the functionality provided in the > CLI commands of the executables. > > An example to illustrate what this might look like can be seen here: > https://github.com/mcarlin/zfs/commit/660cc435543596284a218bf773cf1087829ebde8 > > I'd greatly appreciate everyone's thoughts on this and to see if this is > something the community would be on board with. > > Thanks, > > Mike Carlin > *openzfs <https://openzfs.topicbox.com/latest>* / openzfs-developer / see > discussions <https://openzfs.topicbox.com/groups/developer> + participants > <https://openzfs.topicbox.com/groups/developer/members> + delivery options > <https://openzfs.topicbox.com/groups/developer/subscription> Permalink > <https://openzfs.topicbox.com/groups/developer/Tdde1f0006baa1227-M4c1229e160c31935bc0ff42b> > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Tdde1f0006baa1227-Md33c32ea5a5db44f2fbcf1a3 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
