Libguestfs - Jan 2015 - Re: [PATCH 00/16] btrfs: add support to btrfs scrub, balance, rescue and inspect

On Wed, Jan 21, 2015 at 01:58:02PM +0000, Richard W.M. Jones
wrote:
> On Fri, Jan 16, 2015 at 10:23:35AM +0800, Hu Tao wrote:
> [...]
> 
> Thanks for these patches.  I will push all of them shortly *except*:
Thanks!
> 
> >   New API: btrfs_balance_status
> >   New API: btrfs_scrub_status
> 
> - These ones currently dump the status into a string.  Generally it's
> better (although a huge pain) to translate the output of the commands
> into structures.  The reason is that if we don't do this then we end
> up pushing parsing to every consumer of libguestfs.
I'll redo these two.
> 
> >   New API: btrfs_inspect_rootid
> >   New API: btrfs_inspect_subvolid_resolve
> >   New API: btrfs_inspect_inode_resolve
> >   New API: btrfs_inspect_logical_resolve
> 
> In my version of btrfs, 'btrfs inspect' does not exist, but
'btrfs
> inspect-internal' does exist.  This appears to indicate that these
> APIs are for internal use and not general consumption.  But I'm no
> expert -- if you can point to some official btrfs information which
> says that these btrfs APIs are OK for general consumption and will be
> supported for a long time, then we can use them.
Sorry for confusing! 'btrfs inspect' is short for 'btrfs
inspect-internal'.
I'll resend these patches with the complete command name.

Regards,
Hu
> 
> Thanks,
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.org

On Tue, Jan 27, 2015 at 09:24:35AM +0800, Hu Tao wrote:
> On Wed, Jan 21, 2015 at 01:58:02PM +0000, Richard W.M. Jones wrote:
> > On Fri, Jan 16, 2015 at 10:23:35AM +0800, Hu Tao wrote:
> > [...]
> > 
> > Thanks for these patches.  I will push all of them shortly *except*:
> 
> Thanks!
> 
> > 
> > >   New API: btrfs_balance_status
> > >   New API: btrfs_scrub_status
> > 
> > - These ones currently dump the status into a string.  Generally
it's
> > better (although a huge pain) to translate the output of the commands
> > into structures.  The reason is that if we don't do this then we
end
> > up pushing parsing to every consumer of libguestfs.
> 
> I'll redo these two.
> 
> > 
> > >   New API: btrfs_inspect_rootid
> > >   New API: btrfs_inspect_subvolid_resolve
> > >   New API: btrfs_inspect_inode_resolve
> > >   New API: btrfs_inspect_logical_resolve
> > 
> > In my version of btrfs, 'btrfs inspect' does not exist, but
'btrfs
> > inspect-internal' does exist.  This appears to indicate that these
> > APIs are for internal use and not general consumption.  But I'm no
> > expert -- if you can point to some official btrfs information which
> > says that these btrfs APIs are OK for general consumption and will be
> > supported for a long time, then we can use them.
> 
> Sorry for confusing! 'btrfs inspect' is short for 'btrfs
inspect-internal'.
> I'll resend these patches with the complete command name.
How about keep the API names(a.k.a btrfs_inspect_rootid rather than
btrfs_inspect_internal_rootid) for convinence? The only problem is it
may cause confusing.

Regards,
Hu
> 
> Regards,
> Hu
> 
> > 
> > Thanks,
> > Rich.
> > 
> > -- 
> > Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > libguestfs lets you edit virtual machines.  Supports shell scripting,
> > bindings from many languages.  http://libguestfs.org
> 
> _______________________________________________
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs

The real problem is not the name, but this:
> This appears to indicate that these
> APIs are for internal use and not general consumption.  But I'm no
> expert -- if you can point to some official btrfs information which
> says that these btrfs APIs are OK for general consumption and will be
> supported for a long time, then we can use them.
Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW