Re: [PATCH] btrfs: Move on-disk structure definition to btrfs_tree.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 07, 2020 at 09:43:12PM +0800, Qu Wenruo wrote:
> 
> 
> On 2020/4/7 下午9:14, David Sterba wrote:
> > On Tue, Apr 07, 2020 at 04:44:33PM +0800, Qu Wenruo wrote:
> >> These structures all are on-disk format. Move them to btrfs_tree.h
> >>
> >> This move includes:
> >> - btrfs magic
> >>   It's a surprise that it's not even definied in btrfs_tree.h
> >>
> >> - tree block max level
> >>   Move it before btrfs_header definition.
> >>
> >> - tree block backref revision
> >> - btrfs_header structure
> >> - btrfs_root_backup structure
> >> - btrfs_super_block structure
> >> - BTRFS_FEATURE_* flags
> >>
> >> - btrfs_item structure
> >> - btrfs_leaf structure
> >> - btrfs_key_ptr structure
> >> - btrfs_node structure
> >>
> >> - BTRFS_INODE_* flags
> >>   Move them before btrfs_inode_item definition.
> >>
> >> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
> >> ---
> >> This moved btree_tree.h is more appropriate for btrfs-progs to reuse.
> > 
> > This actually answers 'why' the change is made so this should be in the
> > changelog but I still want to know the reason to move it to the header.
> > Do you mean that progs from git would be built #including this header
> > directly?
> > 
> No. As you answered a long long time before, btrfs-progs shouldn't
> include global kernel header directly.
> 
> Your answer was for case like building btrfs-progs on older kernel, and
> I still believe you're right.

Yes, this still holds.

> For btrfs-progs, I will just cross-port (copy) the header to btrfs-progs.
> 
> The re-use part doesn't only limit to btrfs-progs.
> In fact, there are already two more projects which can benefit from such
> move: grub and u-boot.
> 
> This patch is the base stone for later u-boot cross ports.
> The idea is to use kernel headers (copy them to related projects), then
> re-use a subset of btrfs-progs to implement a full read-only btrfs code
> base in u-boot.

Ok, I understand the motivation, copying and syncing header from one
source is what we want.



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux