DriverDev-Devel Archive on lore.kernel.org
 help / color / Atom feed
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
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().

  reply index

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   ` viro
2019-07-21  3:08     ` hsiangkao
2019-07-21  4:05       ` viro [this message]
2019-07-21  4:12         ` gaoxiang25
2019-07-21 18:05           ` hsiangkao
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 gaoxiang25
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 gaoxiang25
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 gaoxiang25
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   ` hsiangkao
2019-07-15  7:56     ` Pavel Machek
2019-07-15  8:37       ` Gao Xiang

Reply instructions:

You may reply publically 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

DriverDev-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/driverdev-devel/0 driverdev-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 driverdev-devel driverdev-devel/ https://lore.kernel.org/driverdev-devel \
		driverdev-devel@linuxdriverproject.org devel@driverdev.osuosl.org
	public-inbox-index driverdev-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linuxdriverproject.driverdev-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git