From: "Josh Boyer" <jwboyer@gmail.com>
To: dedekind@yandex.ru
Cc: linux-mtd@lists.infradead.org
Subject: Re: State of UBI
Date: Sun, 10 Sep 2006 09:11:04 -0500 [thread overview]
Message-ID: <625fc13d0609100711k1555d439ve7f3e15c63378e87@mail.gmail.com> (raw)
In-Reply-To: <4504146D.000002.20805@webmail12.yandex.ru>
On 9/10/06, dedekind <dedekind@yandex.ru> wrote:
> >> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
> >
> >I'll politely disagree here. UBI _does_ need this on NAND to be
> >really usable. Otherwise you eat 2 pages per block for UBI metadata,
> >and that is quite a bit of overhead for a handful of bytes in the
> >structures.
> Josh, I politely ask you to read what I said once more, sorry :-).
>
> I didn't say the "double page" stuff is not needed. I agree that it *is*
> needed, and is very important!
>
> What I said is that this feature requires *zero changes in UBI code*.
> It requires changes in *MTD* code. So this is why I said it
> does not really relate to UBI itself, it relates to what I called
> "about UBI" in the previous mail. :-) See what I mean?
Sure, I know the changes need to be made in MTD and not UBI. But I
think it's important enough to wait for MTD to get that fix before
merging UBI. I didn't mean to imply that this was somehow a UBI
problem, but rather something that was hindering UBI in general.
Look at it from a user's perspective. Someone tells you that UBI is
really cool and you should use it, but then you find out you have to
spend 4KiB per eraseblock in overhead on large page NAND devices.
It's just not that appealing.
> >> 2. Better UBI utilities as I find the current ones not ideal.
> >What do you find lacking or not ideal? I'm just curious.
>
> I dislike that the utilities accept UBI device number instead of UBI
> character device name. And they internally form the UBI device name
> using hardcoded "/dev/ubi%d" pattern. It it insane. I may want to name
> my UBI devices differently.
Hm, ok. I haven't looked, but that doesn't sound too hard to fix.
Perhaps the current behavior could be left as default.
> I'm partially guilty in this because I started the libubi library with
> this insane feature. But I wrote it for my tests and didn't mean to
> use it as a generic library. Then I created a new sane version of ubilib
> but people had written most of the UBI utilities using the old insane one
> by that time...
Well, nothing has been merged yet so it's easy to fix
> Also, the ubimkvol utility works only for ubi0 device and does not
> work for ubi1 device. I did not dig why.
Sounds like a bug to me.
josh
next prev parent reply other threads:[~2006-09-10 14:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-10 2:22 State of UBI Josh Boyer
2006-09-10 8:47 ` dedekind
2006-09-10 10:52 ` David Woodhouse
2006-09-10 12:35 ` Josh Boyer
2006-09-10 13:19 ` dedekind
2006-09-10 17:00 ` dedekind
2006-09-10 17:44 ` David Woodhouse
2006-09-11 6:11 ` dedekind
2006-09-10 12:32 ` Josh Boyer
2006-09-10 13:34 ` dedekind
2006-09-10 14:11 ` Josh Boyer [this message]
2006-09-10 14:23 ` dedekind
2006-09-11 8:11 ` David Woodhouse
2006-09-11 9:19 ` dedekind
2006-09-11 13:21 ` Josh Boyer
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=625fc13d0609100711k1555d439ve7f3e15c63378e87@mail.gmail.com \
--to=jwboyer@gmail.com \
--cc=dedekind@yandex.ru \
--cc=linux-mtd@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox