All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: Move on-disk structure definition to btrfs_tree.h
Date: Tue, 7 Apr 2020 21:43:12 +0800	[thread overview]
Message-ID: <2751ebbf-dfc4-b453-b807-17e86be43929@gmx.com> (raw)
In-Reply-To: <20200407131414.GS5920@twin.jikos.cz>


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



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@suse.com>
>> ---
>> 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.

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.

Thanks,
Qu


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

  reply	other threads:[~2020-04-07 13:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07  8:44 [PATCH] btrfs: Move on-disk structure definition to btrfs_tree.h Qu Wenruo
2020-04-07 13:14 ` David Sterba
2020-04-07 13:43   ` Qu Wenruo [this message]
2020-04-07 14:57     ` David Sterba
2020-04-07  8:44 Qu Wenruo
2020-04-10 19:20 ` Josef Bacik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2751ebbf-dfc4-b453-b807-17e86be43929@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.