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
signature.asc
Description: OpenPGP digital signature
