From: viro@zeniv.linux.org.uk (Al Viro)
Subject: [PATCH v2 03/24] erofs: add super block operations
Date: Sun, 21 Jul 2019 05:05:53 +0100 [thread overview]
Message-ID: <20190721040547.GF17978@ZenIV.linux.org.uk> (raw)
In-Reply-To: <161cffc4-1d61-5dc6-45df-f1779ef03b0f@aol.com>
On Sun, Jul 21, 2019@11:08:42AM +0800, Gao Xiang wrote:
> It is for debugging use as you said below, mainly for our internal
> testers whose jobs are
> to read kmsg logs and catch kernel problems. sb->s_id (device number)
> maybe not
> straight-forward for them compared with dev_name...
Huh? ->s_id is something like "sdb7" - it's bdev_name(), not a device
number...
> The initial purpose of erofs_mount_private was to passing multi private
> data from erofs_mount
> to erofs_read_super, which was written before fs_contest was introduced.
That has nothing to do with fs_context (well, other than fs_context conversions
affecting the code very close to that).
> I agree with you, it seems better to just use s_id in community and
> delete erofs_mount_private stuffs...
> Yet I don't look into how to use new fs_context, could I keep using
> legacy mount interface and fix them all?
Sure.
> I guess if I don't misunderstand, that is another suggestion -- in
> short, leave all destructors to .kill_sb() and
> cleanup fill_super().
Just be careful with that iput() there - AFAICS, if fs went live (i.e.
if ->s_root is non-NULL), you really need it done only from put_super();
OTOH, for the case of NULL ->s_root ->put_super() won't be called at all,
so in that case you need it directly in ->kill_sb().
next prev parent reply other threads:[~2019-07-21 4:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 14:57 [PATCH v2 00/24] erofs: promote erofs from staging Gao Xiang
2019-07-11 14:57 ` [PATCH v2 01/24] erofs: add on-disk layout Gao Xiang
2019-07-11 14:57 ` [PATCH v2 02/24] erofs: add erofs in-memory stuffs Gao Xiang
2019-07-11 14:57 ` [PATCH v2 03/24] erofs: add super block operations Gao Xiang
2019-07-20 22:49 ` Al Viro
2019-07-21 3:08 ` Gao Xiang
2019-07-21 4:05 ` Al Viro [this message]
2019-07-21 4:12 ` Gao Xiang
2019-07-21 18:05 ` Gao Xiang
2019-07-11 14:57 ` [PATCH v2 04/24] erofs: add raw address_space operations Gao Xiang
2019-07-11 14:57 ` [PATCH v2 05/24] erofs: add inode operations Gao Xiang
2019-07-11 14:57 ` [PATCH v2 06/24] erofs: support special inode Gao Xiang
2019-07-11 14:57 ` [PATCH v2 07/24] erofs: add directory operations Gao Xiang
2019-07-11 14:57 ` [PATCH v2 08/24] erofs: add namei functions Gao Xiang
2019-07-11 14:57 ` [PATCH v2 09/24] erofs: support tracepoint Gao Xiang
2019-07-11 14:57 ` [PATCH v2 10/24] erofs: update Kconfig and Makefile Gao Xiang
2019-07-11 14:57 ` [PATCH v2 11/24] erofs: introduce xattr & posixacl support Gao Xiang
2019-07-11 14:57 ` [PATCH v2 12/24] erofs: introduce tagged pointer Gao Xiang
2019-07-11 14:57 ` [PATCH v2 13/24] erofs: add compression indexes support Gao Xiang
2019-07-11 14:57 ` [PATCH v2 14/24] erofs: introduce superblock registration Gao Xiang
2019-07-11 14:57 ` [PATCH v2 15/24] erofs: introduce erofs shrinker Gao Xiang
2019-07-11 14:57 ` [PATCH v2 16/24] erofs: introduce workstation for decompression Gao Xiang
2019-07-11 14:57 ` [PATCH v2 17/24] erofs: introduce per-CPU buffers implementation Gao Xiang
2019-07-11 14:57 ` [PATCH v2 18/24] erofs: introduce pagevec for decompression subsystem Gao Xiang
2019-07-11 14:57 ` [PATCH v2 19/24] erofs: add erofs_allocpage() Gao Xiang
2019-07-11 14:57 ` [PATCH v2 20/24] erofs: introduce generic decompression backend Gao Xiang
2019-07-11 14:57 ` [PATCH v2 21/24] erofs: introduce LZ4 decompression inplace Gao Xiang
2019-07-11 14:57 ` [PATCH v2 22/24] erofs: introduce the decompression frontend Gao Xiang
2019-07-11 14:57 ` [PATCH v2 23/24] erofs: introduce cached decompression Gao Xiang
2019-07-11 14:57 ` [PATCH v2 24/24] erofs: add document Gao Xiang
2019-07-14 10:49 ` [PATCH v2 00/24] erofs: promote erofs from staging Pavel Machek
2019-07-14 20:17 ` Gao Xiang
2019-07-15 7:56 ` Pavel Machek
2019-07-15 8:37 ` Gao Xiang
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=20190721040547.GF17978@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).