On Fri, Jun 28, 2019 at 2:01 PM Zhihao Cheng <chengzhihao1@xxxxxxxxxx> wrote: > > The UBI device can be attached to a MTD device via fastmap by setting > CONFIG_MTD_UBI_FASTMAP to 'y' (If there already exists a fastmap on the > UBI device). To support some debugging scenarios, attaching process by > fastmap can be confirmed in dmesg. If the UBI device is attached by > fastmap, logs like following will appear in dmesg: > > ubi0: attached by fastmap > > If multiple UBI devices are attached to multiple MTD devices at the same > time, how to distinguish which UBI devices are successfully attached by > fastmap? Extracting attaching information for each UBI device one by one > from dmesg is a way. A better method is to record fastmap existence in > sysfs, so it can be obtained by userspace tools. > > This patch exposes fastmap on sysfs. Suppose you attach an UBI device to a > MTD device by fastmap: if fastmap equals to '1', that is, the fastmap > generated before last detaching operation is confirmed valid. Else, there > may be some problems with old fastmap. Besides, userspace tool can also > check whether the fastmap updating triggered by other operations (such as > resize volume) is successful by reading this sysfs attribute. > > Signed-off-by: Zhihao Cheng <chengzhihao1@xxxxxxxxxx> Sorry for the delay. [...] No locks in sysfs, please. :-) > + ret = sprintf(buf, "%d\n", ubi->fm ? 1 : 0); > + up_write(&ubi->fm_protect); > + } else So, I like the idea to expose that information and I gave it a second thought. Basically you want to export two distinct infos. 1. Did we attach using fastmap? 2. Is *currently* a fastmap on the flash? For 1, just expose ubi->fast_attach via sysfs. To expose 2, you need to create a shadow variable of ubi->fm. The problem is ubi->fm is internal and can be NULL while an update happens. -- Thanks, //richard ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/