[PATCHv2 4/5] libmtd: add support for 64-bit offsets, OOB

[Artem Bityutskiy]

On Tue, 2010-07-13 at 13:49 +0300, Artem Bityutskiy wrote:
> On Wed, 2010-07-07 at 17:30 -0700, Kevin Cernekee wrote:
> > Change mtd_erase() so that it attempts to use MEMERASE64 first, then falls
> > back to the old <2.6.31 MEMERASE if MEMERASE64 is unsupported.
> > 
> > Add mtd_read_oob(), mtd_write_oob() functions to wrap the OOB ioctls.
> > Similar ioctl fallback logic is used in these functions as well.
> > 
> > Signed-off-by: Kevin Cernekee <cernekee at gmail.com>
> > ---
> >  include/libmtd.h |   36 ++++++++++++++++++++++-
> >  lib/libmtd.c     |   82 ++++++++++++++++++++++++++++++++++++++++++++++++++---
> >  2 files changed, 111 insertions(+), 7 deletions(-)
> > 
> > diff --git a/include/libmtd.h b/include/libmtd.h
> > index 0aea966..292d8c3 100644
> > --- a/include/libmtd.h
> > +++ b/include/libmtd.h
> > @@ -66,6 +66,7 @@ struct mtd_info
> >   * @region_cnt: count of additional erase regions
> >   * @writable: zero if the device is read-only
> >   * @bb_allowed: non-zero if the MTD device may have bad eraseblocks
> > + * @legacy_ioctls: non-zero if the kernel lacks MEMERASE64, MEM*OOB64
> >   */
> >  struct mtd_dev_info
> >  {
> > @@ -84,6 +85,7 @@ struct mtd_dev_info
> >  	int region_cnt;
> >  	unsigned int writable:1;
> >  	unsigned int bb_allowed:1;
> > +	unsigned int legacy_ioctls:1;
> >  };
> 
> Kevin, I'm sorry, but thinking about this some more, this is not a
> property of mtd device, this is a property of whole mtd subsystem. So
> this flag should live in 'struct mtd_info', just like the 'unsigned int
> sysfs_supported:1;' field.
> 
> You should find out whether the new ioctl's are supported in
> 'libmtd_open()'. This also means that all libmtd calls which need this
> flag will need a 'libmtd_t desc' parameter.
> 
> Also, is it possible to have 2 separate patches - 1st adds support for
> 64-bit offest, second adds OOB calls.
> 
> Is this doable? I think this should not be too difficult to change.

I thought some more, and no, this is not doable because you need a
device node, which you do not have when the library is being
initialized. I'll take a look at these patches once again.

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