From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by bombadil.infradead.org with esmtps (Exim 4.68 #1 (Red Hat Linux)) id 1L4tXT-0001Hu-PR for linux-mtd@lists.infradead.org; Tue, 25 Nov 2008 08:44:56 +0000 Message-ID: <492BBD13.7040408@nokia.com> Date: Tue, 25 Nov 2008 10:53:39 +0200 From: Adrian Hunter MIME-Version: 1.0 To: ext Richard Titmuss Subject: Re: Adding -N volume name to ubi utils References: <492ADF69.8060602@logitech.com> In-Reply-To: <492ADF69.8060602@logitech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-mtd@lists.infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Richard Titmuss wrote: > I am trying to modify the ubi tools in mtd_utils to allow the ubi volume > name to be specified on the command line, the relevant commands are > ubinfo, ubirmvol and ubiupdatevol. The idea is that you could use any of > the following command arguments to specify a ubi volume: > > ubirmvol /dev/ubi0 -N rootfs # ubi device node and volume name > ubirmvol /dev/ubi0 -n 1 # ubi device node and volume id > ubirmvol /dev/ubi0_1 # ubi volume node > > Other than consistency the main feature this adds is support for using > -N to specify the volume by name to all the commands. > > The problem is these commands need different information to work: > - ubinfo loads information from the /sys file system, it's easy to > support for all the above command arguments. > - ubirmvol needs a ubi device node and a volume id, how can this work if > a volume node is specified? > - ubiupdatevol needs a ubi volume node, how can this work if a device > node is specified? > > So my questions is how can the appropriate device node be generated by > these commands if it is not specified on the command line. It would be > possible to use something like: > sprintf(node, "/dev/ubi%d_%d", args.devn, args.vol_id); > > However I don't think that hard coding the /dev path is an acceptable > solution, and assume that's why the -d (device number) argument was > deprecated. Does anyone have any suggestions on a better solution? In principle, you should use udev rules to create device nodes that are easy to work with e.g. /dev/ubi/rootfs/vol /dev/ubi/rootfs/dev so then you can make a script say ubirmvolbyname #!/bin/sh ubirmvol /dev/ubi/$1/dev -N $1