Re: udev problem (and fix) for /dev/mtdblock*

[David Brownell <david-b@pacbell.net>]

On Sunday 22 March 2009, Kay Sievers wrote:
> On Fri, Mar 20, 2009 at 19:46, David Brownell <david-b@pacbell.net> 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