From: Zhihao Cheng <chengzhihao1@huawei.com>
To: Eric Sandeen <sandeen@redhat.com>, <linux-mtd@lists.infradead.org>
Cc: <brauner@kernel.org>, David Howells <dhowells@redhat.com>,
Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH] ubifs: Convert ubifs to use the new mount API
Date: Mon, 30 Sep 2024 09:22:46 +0800 [thread overview]
Message-ID: <3418947d-36ad-0fe9-e27c-0fd0540f0918@huawei.com> (raw)
In-Reply-To: <fde1e3c9-f3ba-450c-ae5d-83abb912d2fe@redhat.com>
在 2024/9/30 0:46, Eric Sandeen 写道:
> On 9/28/24 8:57 PM, Zhihao Cheng wrote:
>> Above modification can fix the problem, but it looks not so clean.
>> There are two main steps for mount/remount in the new API framework:
>> 1. Get filesystem configurations by parsing the paramaters from the user data.
>> 2. Apply the filesystem configurations to superblock(For mount, a superblock should be allocated first.).
>>
>> So, how about doing that like ext4 does:
>> 1) the filesystem specified superblock is allocated in fill_super(), not in init_fs_context(), it looks more reasonable, because filesystem doesn't need a new private superblock in remounting process. But, UBIFS has onething different, sb_test() needs volume information which comes from private superblock, so UBFIS private superblock(struct ubifs_info) is allocated in ubifs_mount(). Here, I prefer to keep private superblock allocation still in ubifs_mount(for new mount API, it is called ubifs_get_tree).
>> 2) the filesystem configurations(contains mount options) are stored in a separated structure(in ext4, it is called ext4_fs_context), which is allocated in init_fs_context(). For UBIFS, we can define a similar structure to store the filesystem configurations.
>
> Yes, this is what I had mentioned above, i.e. having a separate mount
> context in ->fs_private raather than using ->fs_info, I can do it this
> way if you prefer. I had just started with dhowell's original
> implementation for speed. :)
Fine, we've come to an agreement.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2024-09-30 1:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-26 20:36 [PATCH] ubifs: Convert ubifs to use the new mount API Eric Sandeen
2024-09-26 20:39 ` Eric Sandeen
2024-09-27 7:47 ` Christian Brauner
2024-09-27 14:12 ` Zhihao Cheng
2024-09-27 14:15 ` Zhihao Cheng
2024-09-27 15:56 ` Eric Sandeen
2024-09-29 1:57 ` Zhihao Cheng
2024-09-29 2:03 ` Zhihao Cheng
2024-09-29 16:46 ` Eric Sandeen
2024-09-30 1:22 ` Zhihao Cheng [this message]
2024-10-01 20:20 ` Eric Sandeen
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=3418947d-36ad-0fe9-e27c-0fd0540f0918@huawei.com \
--to=chengzhihao1@huawei.com \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=sandeen@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox