From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751202AbdE2MIf (ORCPT ); Mon, 29 May 2017 08:08:35 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:57406 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750989AbdE2MId (ORCPT ); Mon, 29 May 2017 08:08:33 -0400 Date: Mon, 29 May 2017 13:08:25 +0100 From: Al Viro To: Richard Weinberger Cc: Rabin Vincent , dedekind1@gmail.com, adrian.hunter@intel.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Rabin Vincent , linux-fsdevel , Christoph Hellwig Subject: Re: Setting ->s_dev to a char device (Was: Re: [PATCH v2] ubifs: allow userspace to map mounts to volumes) Message-ID: <20170529120818.GA6365@ZenIV.linux.org.uk> References: <1496042533-17024-1-git-send-email-rabin.vincent@axis.com> <6737a526-18ba-6d8c-f6c8-03f03d74b90a@nod.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6737a526-18ba-6d8c-f6c8-03f03d74b90a@nod.at> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 29, 2017 at 01:50:30PM +0200, Richard Weinberger wrote: > CC'ing VFS folks > > Am 29.05.2017 um 09:22 schrieb Rabin Vincent: > > From: Rabin Vincent > > > > There currently appears to be no way for userspace to find out the > > underlying volume number for a mounted ubifs file system, since ubifs > > uses anonymous block devices. The volume name is present in > > /proc/mounts but UBI volumes can be renamed after the volume has been > > mounted. > > > > To remedy this, provide a directory in /sys/fs/ubifs named after the > > underlying anonymous block device's number (obtainable by userspace via > > stat(2)) and provide a link named "ubi" to the underlying UBI volume. > > I wonder whether it would make more sense to just assign the character device > number of the UBI volume to ->s_dev. > Then userspace can query the underlying device without additional sysfs > magic. > > Sure if userspace expects a block number from UBIFS it will get confused. > > Comments? Userspace sure as hell does. st_dev in stat(2) is a block device number; moreover, there might _be_ a block device with the same number at the same time - even mounted. Why not make ->show_options() print the currently valid volume name, anyway? That would seem to be the obvious approach...