On Fri, Apr 24, 2020 at 10:24:45PM +0200, David Sterba wrote:
> On Tue, Apr 21, 2020 at 07:41:40PM +0800, Qu Wenruo wrote:
> >
> >
> > On 2020/4/21 下午7:31, Christoph Hellwig wrote:
> > > On Wed, Apr 15, 2020 at 04:41:12PM +0800, Qu Wenruo wrote:
> > >> These structures all are on-disk format. Move them to btrfs_tree.h
> > >>
> > >> This allows us to sync the header to different projects, who need to
> > >> read btrfs filesystem, like U-boot, grub.
> > >
> > > Please use a separate header for that. btrfs_tree.h is a UAPI header
> > > with strict ABI guarantees. Just add a fs/btrfs/btrfs_format.h that
> > > can be copied into the projects where is needed.
> > >
> > Doesn't on-disk format itself need strict ABI guarantees?
> >
> > Thus it looks like the perfect location for on-disk format definitions.
>
> Right now I'm not sure if it's a good idea to put the on-disk format to
> the UAPI path or not. The exported code is to support the ioctls,
> there's an overlap with the on-disk format but providing all the on-disk
> structures for general might become an unnecessry burden.
>
> We know that there's a small number of projects that want to sync the
> on-disk format so I don't think it's going to be a problem for them to
> use a private header.
And the usual way is to just ensure the format header is self-contained
and suitably licensed that they can easily copy it and rely on the
version they checked in. That avoids the problems of
a) the tools relying on installed kernel headers new enough for the
feature they want to support
b) ifdef magic for newer features in the tools
c) the need to keep changes to the kernel format header to be backwards
compatible at the compiler level (as there can be disk format
compatible changes that still break users, e.g. introducing a named
union, or splitting / merging struct definitions)
