From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Static UBI volumes and ubiupdatevol ?
Date: Fri, 17 Dec 2010 14:40:34 +0200 [thread overview]
Message-ID: <1292589634.2412.11.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.1012171328380.7024@lnxricardw.se.axis.com>
On Fri, 2010-12-17 at 13:31 +0100, Ricard Wanderlof wrote:
> On Fri, 17 Dec 2010, Artem Bityutskiy wrote:
>
> > Ah, yes, you see, you know the things quite well yourself :-)
>
> Well, I try to convince myself that I think I know, but there's always the
> very real and likely possibilty that I'm wrong because I've misunderstood
> something.
>
> >> I guess I could read from the /dev/ubix_y device to just get the raw UBIFS
> >> data which shouldn't change even in the event of scrubbing? Or should I
> >> use gluebi to get both a raw mtd partition corresponding to the raw UBIFS
> >> data, as well as using UBIFS (on /dev/ubix_y) for the file system?
> >
> > No, gluebi is not needed, it would just give you an /dev/mtdZ device
> > with contents equivalent to /dev/ubiX_Y
>
> So what does gluebi in fact add, does it just supply all the necessary
> ioctl's to make /dev/ubiX_Y look like a /dev/mtdZ device, in addition to
> the already existing functionality of being able to read and write to the
> volume using read and write? (Yes, I could dig through the code, but even
> though it might give me the answer on what it looks like right now, it
> might not tell what the intention was...).
Original idea was to put JFFS2 on top of UBI volumes. Gluebi is doing
just that - turns UBI volume into an MTD device, then you have mount it
with JFFS2.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
prev parent reply other threads:[~2010-12-17 12:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-15 8:06 Static UBI volumes and ubiupdatevol ? Ricard Wanderlof
2010-12-15 10:43 ` Ricard Wanderlof
2010-12-16 16:26 ` Artem Bityutskiy
2010-12-17 9:39 ` Ricard Wanderlof
2010-12-17 13:04 ` Artem Bityutskiy
2010-12-17 15:02 ` Ricard Wanderlof
2010-12-17 17:05 ` Artem Bityutskiy
2010-12-29 20:26 ` Russ Dill
2010-12-16 16:19 ` Artem Bityutskiy
2010-12-17 9:33 ` Ricard Wanderlof
2010-12-17 12:26 ` Artem Bityutskiy
2010-12-17 12:31 ` Ricard Wanderlof
2010-12-17 12:40 ` Artem Bityutskiy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1292589634.2412.11.camel@localhost \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=ricard.wanderlof@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.