<linux/btrfs.h> contents incomplete (?)

<linux/btrfs.h> contents incomplete (?)

[Jeff Mahoney]

[-- Attachment #1.1: Type: text/plain, Size: 1727 bytes --]

Hi all -

I recently spent some time writing up btrfs ioctl decoding for strace to
be used in debugging various third party tools (e.g. snapper) in their
interactions with btrfs.[1]  In doing so, I found that substantial parts
of the tree interface haven't been exported via <linux/btrfs.h>.  For my
purposes, it was mostly flags and two structures passed in as ioctl
arguments. All things that are intended to be part of the API.  But as I
started to write up a patch to remedy that, I realized that we've
basically exported most of the file system internals via the SEARCH_TREE
ioctl.  In fact, the SEARCH_TREE ioctl is the intended interface for a
number of features (e.g. qgroup status).  As a result, pretty much every
item type, objectid values, etc are part of the API and should be
published via <linux/btrfs.h> for consumers.

I'm happy to do the lifting to move things around to make this happen,
but before I do, I wanted to ask:

Is it expected that consumers of the interface at this low a level will
provide their own copies of the structures, flags, types, and objectid
values they want to consume?  If so, why?  These are all on-disk format
values and effectively set in stone.  At least the ones that are already
defined.  Wouldn't things like new flags and reserved values being
claimed cause API drift pretty quickly and put the maintenance burden on
the third party developer?

-Jeff

[1] It's also pretty neat in that you can just write a quick program to
run an ioctl and not have to bother decoding most of it -- just look at
the strace output.  I do provide symbolic names for tree ids and key
types, but don't decode the item contents.

-- 
Jeff Mahoney
SUSE Labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]