Re: [PATCH 1/1] ubi: Allow ubiblock devices nodes to be created by volume name instead of volume ID.

[Emil Lenngren <emil.lenngren@gmail.com>]

Hi Richard,

Den sön 18 aug. 2019 kl 22:50 skrev Richard Weinberger
<richard.weinberger@gmail.com>:
>
> On Wed, Aug 14, 2019 at 2:34 PM Emil Lenngren <emil.lenngren@gmail.com> wrote:
> > > Isn't this why we have udev, to create fancy by-id/by-path/... naming conventions?
> > >
> > > Thanks,
> > > //richard
> >
> > I actually implemented the same change some time ago, for the exact
> > same reason (swapping two volumes and then reboot). Referring to an
> > ubi volume by name is more convenient than volume numbers, since names
> > can be changed and numbers can't.
> > Is it maybe possible to define both /dev/ubiblock%d_%d and
> > /dev/ubiblock%d_%s at the same time?
> > How would this be done with udev instead to get "fancy by-id"?
>
> Thanks for bringing this topic up again.
> udev allows rules and even helper (scripts) to gain device
> attributes. These can then be used to name/symlink devices as you want.
>
> For example, if you want to have device symlinks by name for UBI
> volumes, you can create a rule like that:
> KERNEL=="ubi?_?", IMPORT{program}="/etc/udev/rules.d/ubi_probe
> $devnode", SYMLINK="ubi%E{MTD_NUM}_%E{VOL_NAME}"
>
> With ubi_probe being:
> #!/bin/sh
> VOL_NAME="$(cat /sys/${DEVPATH}/name)"
> MTD_NUM="$(cat /sys/${DEVPATH}/../mtd_num)"
> echo "VOL_NAME=${VOL_NAME}"
> echo "MTD_NUM=${MTD_NUM}"
>
> I took the chance and reviewed UBI's sysfs interface and found a few
> things which need
> improvement. With these issues addressed you can also work with
> ubiblock by name:
> 1. UBI does not export the UBI device number via sysfs. In 99% of all
> cases mtd_num will be correct,
> but you can select the UBI number upon attach time.
> 2. UBI does not emit a change kevent when an volume is renamed. So
> udev does not see the rename command.
> 3. ubiblock does not set the UBI volume as parent device.
>
> So we can then have a rule like:
> KERNEL=="ubiblock?_?",
> IMPORT{program}="/etc/udev/rules.d/ubiblock_probe $devnode"
> SYMLINK="ubiblock$number_%E{VOL_NAME}"
>
> With ubiblock_probe being:
> #!/bin/sh
> VOL_NAME="$(cat /sys/${DEVPATH}/device/name)"
> echo "VOL_NAME=${VOL_NAME}"
>
> # ls -ltr /dev/ubiblock*
> brw-rw---- 1 root disk 251, 0 18. Aug 22:41 /dev/ubiblock7_0
> lrwxrwxrwx 1 root root     11 18. Aug 22:41 /dev/ubiblock0_test -> ubiblock7_0
> # ubirename /dev/ubi7 test lala
> # ls -ltr /dev/ubiblock*
> brw-rw---- 1 root disk 251, 0 18. Aug 22:42 /dev/ubiblock7_0
> lrwxrwxrwx 1 root root     11 18. Aug 22:42 /dev/ubiblock0_lala -> ubiblock7_0
>
> Does this help? If you need other/more sysfs changes, please tell. :-)
> Attached you can find my WIP patch for these changes. I need to double check
> a few things first before I will send a formal patch.
>
> I think it would even make sense to integrate a more powerful
> ubi_probe (as C program) into systemd-udev
> like we already have for mtd itself.

Will this really work when passing the rootfs to the kernel command
line like "root=/dev/ubiblock0_rootfs"? If the udev rules that set up
the symbolic link /dev/ubiblock0_rootfs are stored in a file on the
rootfs itself, I guess that symlink can't be made available before the
rootfs is mounted...

/Emil

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/