From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from edmz-nat.slimdevices.com ([209.220.154.2] helo=mail.slimdevices.com) by bombadil.infradead.org with esmtp (Exim 4.68 #1 (Red Hat Linux)) id 1L4eui-0006y6-T4 for linux-mtd@lists.infradead.org; Mon, 24 Nov 2008 17:07:57 +0000 Received: from [127.0.0.1] (host217-44-198-192.range217-44.btcentralplus.com [217.44.198.192]) by mail.slimdevices.com (Postfix) with ESMTPA id D3D264B022 for ; Mon, 24 Nov 2008 09:07:54 -0800 (PST) Message-ID: <492ADF69.8060602@logitech.com> Date: Mon, 24 Nov 2008 17:07:53 +0000 From: Richard Titmuss MIME-Version: 1.0 To: linux-mtd@lists.infradead.org Subject: Adding -N volume name to ubi utils Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, 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? Thanks, Richard