On Sunday 22 March 2009, Kay Sievers wrote: > On Fri, Mar 20, 2009 at 19:46, David Brownell <david-b@xxxxxxxxxxx> wrote: > > ... etc, dating from last fall ... > > >> > KERNEL=="ram*|loop*|fd*|mtd*|nbd*|gnbd*|dm-*|md*", GOTO="persistent_storage_end" > >> > > >> > It'd be good to see this bug fixed before lenny goes final... > >> > >> Udev, by default, investigates all block devices which are created by > >> the kernel. > > > > Except for the seven exceptions listed above... > > Loop is no longer there today, ram can also be removed. The others are > remote network devices, which are difficult to handle, and can not be > identified at creation event time. Floppies do not detect any media > changes, and are excluded for that reason. Dm and md have their own > rules. All beside the point. That's not "all" block devices; and "mtdblock" should be in that exception list. The problem is that MTDs don't support the model implemented in the rest of that file > >> People use label/uuid and other metadata based stuff, so > >> we should look at them. > > > > Yes, people are stupid too. Such things are basically > > meaningless for MTDs. > > Maybe, but seems they are used, because mtd currently does not offer > any other attributes to identify a device. > > > They don't have labels as those > > tools understand them, and partition data is normally > > part of board-specific kernel configuration data (or > > even kernel command line data passed from bootloaders). If "they are used", it's by a decided minority of MTDs. Th > > And there's MTD-specific metadata, like the OTP bits > > provided on most modern chips and which MTD technology > > is used by that device. > > If we can provide any other useful data to identify devices, it would > be nice, if someone could make that work. Can such attributes somehow > be added to sysfs? In some cases, maybe ... thing is that OTP (One Time Programmable) bits vary widely in terms of structure, size, and even presence. OTP data in lot of the NAND chips I have here exceeds the sysfs 4KB binary file limit; 20KB commonly, 128KB for OneNand. That's enough that some systems would not want to model it as metadata. And the "manufacturer" data (basically, chip-specific IDs) are not always documented such that GPL'd code could access them. > MTD currently creates all devices as "virtual", it does not even use > the proper parent devices in the kernel, which would at least allow a > very simple identification, based on the underlying platform device > properties. That would be an entirely separate problem though. ISTR having a similar "WTF is this doing" reaction last time I had to look at MTD core driver model stuff. > I keep an untested and unfinished patch around, I did the last time > someone tried to solve the problem of reordered mtd devices with udev > rules: > http://git.kernel.org/?p=linux/kernel/git/kay/patches.git;a=blob;f=mtd-parent-dev.patch;hb=HEAD Looks plausible ... and I may have actually seen a system where that "problem" matters. (Normally all flash drivers are linked statically, and the system root uses one of them.) That obviously needs to be split into "core" (mtd block and char dev support) and driver bits; the core bits could go in at any time once they're ready. FWIW I did a quick test of this on a physmap flash ... didn't work, /sys/devices/virtual/mtd still held everything that was not in /sys/devices/virtual/block/mtdblock*. I think the issue might be lack of mtdpart support. > If we can offer people the information which will be available with > this rather simple change, people can probably switch over to that, > and we can replace the current one. Best to get rid of the currently-broken udev bits first. There's no particular reason MTD couldn't add that other feature though. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
