Re: [PATCH 4/5] UBI: introduce attach ioctls

[Artem Bityutskiy <dedekind@infradead.org>]

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.

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

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)