[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FBC9507.9070200@nod.at>
Date: Wed, 23 May 2012 09:43:03 +0200
From: Richard Weinberger <richard@....at>
To: Shmulik Ladkani <shmulik.ladkani@...il.com>
CC: linux-mtd@...ts.infradead.org, dedekind1@...il.com,
linux-kernel@...r.kernel.org, Heinz.Egger@...utronix.de,
tim.bird@...sony.com, tglx@...utronix.de
Subject: Re: [PATCH] [RFC] UBI: Implement Fastmap support
On 23.05.2012 08:18, Shmulik Ladkani wrote:
>> It removes a PEB from the free rb-tree.
>> ubi->lookuptbl[pnum] does not matter at this time.
>
> For practical matters, you are correct.
> Design wise, it is bit inconsistent and confusing.
>
> On one hand, you claim above that 'ubi->lookuptbl' holds the WL entries
> known to WL subsystem - that is, lookuptbl is a data structure used and
> maintained by the WL subsystem.
> OTOH, when a PEB is removed from hands of WL (by a ubi_wl_get_fm_peb
> call), you keep its WL entry assigned in ubi->lookuptbl.
>
> I'll rethink this, see if there's a potential trouble here.
If I remove the PEB from ubi->lookuptbl I'll have to reread the EC
header upon ubi_wl_put_fm_peb().
Otherwise it's EC value is lost.
>>> However 'ubi_wl_put_fm_peb' creates a 'ubi_wl_entry' if not found in
>>> the lookuptbl.
>> Currently fastmap "fixes" ubi->lookuptbl on demand. Is this a problem?
>
> I guess not.
>
> The only problem, as previously noted, is the failure to create a new
> 'ubi_wl_entry' when the PEB needs to be returned to WL subsystem.
I think I can return them to the lookuptbl while attaching.
Stay tuned, I'll release v7 today or tomorrow.
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists