On Sun, 2007-02-18 at 23:37 +0100, Arnd Bergmann wrote:
> 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.
On Sun, 2007-02-18 at 23:37 +0100, Arnd Bergmann wrote:
> 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
On Sat, 2007-02-17 at 22:14 +0100, Arnd Bergmann wrote:
> This approach doesn't seem to make sense at all. If the MTD device interface
> is flawed, the right approach should be to fix that instead. After all,
> there are not many users of the MTD interface, so you should be able to
> adapt them.
On Sat, Feb 17, 2007 at 08:04:30PM -0600, 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,
On Sat, Feb 17, 2007 at 08:04:30PM -0600, 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,
On Sat, 2007-02-17 at 22:14 +0100, Arnd Bergmann wrote:
This approach doesn't seem to make sense at all. If the MTD device interface
is flawed, the right approach should be to fix that instead. After all,
there are not many users of the MTD interface, so you should be able to
adapt them.
MTD
On Sun, 2007-02-18 at 23:37 +0100, Arnd Bergmann wrote:
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
On Sun, 2007-02-18 at 23:37 +0100, Arnd Bergmann wrote:
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.
Let me
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
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
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
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
On Sat, Feb 17, 2007 at 10:14:54PM +0100, Arnd Bergmann wrote:
> On Saturday 17 February 2007 17:57, Artem Bityutskiy wrote:
> > + * This unit is responsible for emulating MTD devices on top of UBI
> > devices.
> > + * This sounds strange, but it is in fact quite useful to make legacy
> >
On Saturday 17 February 2007 17:57, Artem Bityutskiy wrote:
> + * This unit is responsible for emulating MTD devices on top of UBI devices.
> + * This sounds strange, but it is in fact quite useful to make legacy
> software
> + * work on top of UBI. New software should use native UBI API instead.
diff -auNrp tmp-from/drivers/mtd/ubi/gluebi.h tmp-to/drivers/mtd/ubi/gluebi.h
--- tmp-from/drivers/mtd/ubi/gluebi.h 1970-01-01 02:00:00.0 +0200
+++ tmp-to/drivers/mtd/ubi/gluebi.h 2007-02-17 18:07:28.0 +0200
@@ -0,0 +1,88 @@
+/*
+ * Copyright (c) International Business
diff -auNrp tmp-from/drivers/mtd/ubi/gluebi.h tmp-to/drivers/mtd/ubi/gluebi.h
--- tmp-from/drivers/mtd/ubi/gluebi.h 1970-01-01 02:00:00.0 +0200
+++ tmp-to/drivers/mtd/ubi/gluebi.h 2007-02-17 18:07:28.0 +0200
@@ -0,0 +1,88 @@
+/*
+ * Copyright (c) International Business
On Saturday 17 February 2007 17:57, Artem Bityutskiy wrote:
+ * This unit is responsible for emulating MTD devices on top of UBI devices.
+ * This sounds strange, but it is in fact quite useful to make legacy
software
+ * work on top of UBI. New software should use native UBI API instead.
+
On Sat, Feb 17, 2007 at 10:14:54PM +0100, Arnd Bergmann wrote:
On Saturday 17 February 2007 17:57, Artem Bityutskiy wrote:
+ * This unit is responsible for emulating MTD devices on top of UBI
devices.
+ * This sounds strange, but it is in fact quite useful to make legacy
software
+ *
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
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
20 matches
Mail list logo
