[lkml]   [2007]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 41/44 take 2] [UBI] gluebi unit header
    On Sunday 18 February 2007 04:02:17 Josh Boyer wrote:
    > On Sun, Feb 18, 2007 at 03:15:23AM +0100, Arnd Bergmann wrote:
    > > On Sunday 18 February 2007 03:04, Josh Boyer wrote:
    > > > No, the MTD interface isn't flawed.  gluebi is present to make things
    > > > like JFFS2 work on top of UBI volumes with very little adaptations.  If
    > > > you go changing _every_ MTD user to now use either an MTD device or a
    > > > native UBI device, then the code for those users just gets bloated.
    > >
    > > Right, that was my point. If the MTD API in the kernel is not flawed, why
    > > do we need the 'native' UBI interface? Just merge gluebi into UBI and
    > > get rid of the extra abstraction.
    > That suggestion came up several times.  gluebi represents a compromise
    > between the two groups.  IIRC, the issue was that representing UBI volumes
    > as MTD devices only makes sense in the dynamic volume case.  Static UBI
    > volumes require special write/update handling and so there was a need for
    > a native interface anyway.

    Which brings be back to my original point ;-)

    I'm sure this has been discussed before, but I'd still like to understand
    what is so special with 'static UBI volumes' that they can't be used with
    a slightly extended MTD interface.

    Arnd <><
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-02-18 23:41    [W:0.020 / U:6.896 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site