Adds /dev/block/by-name/<partition> symlinks
During uevent processing, some "by-name" symlinks will be created. /dev/block/<type>/<device>/by-name/<partition> <type> can be: platform, pci or vbd. <device> might be: soc.0/f9824900.sdhci, soc.0/f9824900.sdhci, etc. <partition> might be: system, vendor, system_a, system_b, etc. e.g., on a non-A/B device: /dev/block/platform/soc.0/f9824900.sdhci/by-name/system /dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor On a A/B device: /dev/block/platform/soc/1da4000.ufshc/by-name/system_a /dev/block/platform/soc/1da4000.ufshc/by-name/system_b /dev/block/platform/soc/1da4000.ufshc/by-name/vendor_a /dev/block/platform/soc/1da4000.ufshc/by-name/vendor_b However, those symlinks are "device-specific". This change adds the "generic" symlinks in ueventd, in addition to the existing symlinks, when the possible "boot devices" are specified in device tree. e.g., &firmware_android { compatible = "android,firmware"; boot_devices ="soc/1da4000.ufshc,soc.0/f9824900.sdhci"; } The following symlinks will then be created on the aforementioned non-A/B and A/B devices, respectively. /dev/block/by-name/system /dev/block/by-name/vendor /dev/block/by-name/system_a /dev/block/by-name/system_b /dev/block/by-name/vendor_a /dev/block/by-name/vendor_b Note that both <type> and <device> are skipped in the newly create symlinks. It assumes there is no more than one devices with the same <partition>, which is the assumption of current first stage mount flow. Finally, when 'boot_devices' in DT is absent, it fallbacks to extract 'boot_devices' from fstab settings. e.g., using 'soc/1da4000.ufshc', 'soc.0/f9824900.sdhci' for a fstab with the following content: /dev/block/platform/soc/1da4000.ufshc/by-name/system /dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor Bug: 78613232 Test: adb shell ls /dev/block/by-name Change-Id: Iec920b5a72409b6a2bdbeeb290f0a3acd2046b5d Merged-In: Iec920b5a72409b6a2bdbeeb290f0a3acd2046b5d (cherry picked from commit 8eec38f4)
Loading
Please register or sign in to comment