[PATCH] ubifs: Convert ubifs to use the new mount API
Eric Sandeen
sandeen at redhat.com
Tue Oct 1 13:20:18 PDT 2024
On 9/29/24 8:22 PM, Zhihao Cheng wrote:
> 在 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.
>
Ok - I'm working on this, and I'll set up a virtual mtd device so I
can do some proper initial testing, given the changes from the original.
Thanks,
-Eric
More information about the linux-mtd
mailing list