[PATCH 4/5] UBI: introduce attach ioctls

[Arnd Bergmann]

On Wednesday 19 December 2007, Artem Bityutskiy wrote:
> On Wed, 2007-12-19 at 15:17 +0100, Arnd Bergmann wrote:
> > > +struct ubi_attach_req {
> > > +       int32_t vid_hdr_offset;
> > > +       int32_t data_offset;
> > > +       int32_t mtd_num;
> > > +       uint8_t padding[12];
> > >  };
> > 
> > Can you explain why you need to pass vid_hdr_offset /and/ data_offset here?
> > What is the difference between the two? Can't you autoprobe them if you
> > have the device?
> 
> vid_hdr_offset is the offset of the VID header withing an eraseblock.
> data_offs is where the data starts. We want to be able to let users
> select the VID header offset. Vs data offset - indeed it is redundant
> and might be dropped because UBI may just assume data starts at the next
> min. I/O unit after the VID header.
> 
> We can autoprobe the VID header offset, unless the MTD device is empty,
> in which case UBI automatically formats it.

ok, thanks for the explanation.

> > The reason I'm asking is that I'd really like to make this a simple
> > attribute in sysfs, in the mtd object. The question there is what a
> > user would need to store into that attribute. The device is identified
> > implicitly already, but this looks like you still need two distint
> > integers in order to create an UBI device.
> 
> If the MTD device is already UBI-formatted, the numbers may be read from
> the media. Otherwise, not.

Ok, let me suggest an idea, it probably needs more refinement, but maybe we
can come up with something better based on this:

You can have a simple attribute named 'ubi-probe' in each MTD device in sysfs.
this is only readable, and contains either '0' or '1' in ascii, telling you
whether a UBI device could be found for this device.
This only works for UBI formatted media, and the kernel does not format the
media itself.
IF you want to UBI-format a medium, use a user space tool that writes the
appropriate blocks directly to the /dev/mtd* character device.

	Arnd <><