[PATCH 4/5] UBI: introduce attach ioctls

[Josh Boyer]

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
though?

> > 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?

josh