lkml.org 
[lkml]   [2007]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 41/44 take 2] [UBI] gluebi unit header
    Date
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-18 23:41    [W:4.216 / U:0.480 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site