[PATCH 4/5] UBI: introduce attach ioctls
jwboyer at linux.vnet.ibm.com
Thu Dec 20 17:14:22 EST 2007
On Thu, 20 Dec 2007 22:34:56 +0100
Arnd Bergmann <arnd at arndb.de> wrote:
> > > You can have a simple attribute named 'ubi-probe' in each MTD device in sysfs.
> > Err, why should MTD know something about what sits on top of it? Today
> > it is UBI, tommorrow it is something new and better, e.g., more
> > scalable.
> The way you would implement this is to have the UBI code grab hold of all
> the MTD devices, and create the ubi-probe attribute in them. This is
> something that is easily possible with the device model, provided that
> we can get a 'struct device' embedded into 'struct mtd_info'. I just realized
> that this is currently missing.
You could. Aside from this current discussion, what good would it do
> > So MTD maintains ubi-probe attribute, and has some knowlege about UBI.
> > Well, it is technically possible, but I do not think it would be good
> > design. The same way we could teach MTD to probe if it has JFFS2 on it,
> > or something else...
> The probe on a JFFS2 formatted device is called 'mount', and we have a
> perfectly fine system call interface for that ;-)
That's not a good analogy. MTD still has absolutely no idea what is on
top of it.
> > Yeah, user-space tools could format media. But it is so much appropriate
> > facility to have UBI being able to format it itself. It is really very
> > convenient. Flashes have special state - empty flash, and if the flash
> > is empty - UBI make it UBI-formatted. If the flash has some garbage -
> > UBI does not format it.
> Ok, another idea: just create an UBI device for every MTD device, but don't
> probe until the UBI device is first accessed. That way, you don't need
> any dynamic registration, and you can use an ioctl on the device itself
> in order to do the initial formatting with new parameters.
Why would you carry the memory overhead for those devices if they're
never going to be used?
More information about the linux-mtd