On Sun, Jul 21, 2019 at 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(). _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel