[PATCH 4/4] UBI WL-Subsys: Improvement in prot tree

[xiaochuan-xu]

> > +#define ST_PROTECTION 17
> > +#define U_PROTECTION  11
> > +#define LT_PROTECTION 5
> 
> I doubt these constants make much sense. I would suggest you to get rid
> of them and simplify things. Let's have only one constant instead of 3.


> This will allow us to implement efficient protection queue
>  which you will not need to walk at all.
Sorry, I don't quite follow this meaning.
You mean one protection list (not lists) could filfull the function?

> So I'd suggest you to send a separate "preparation" patch which
> introduces one constant instead of 3. E.g.,
> 
> #define PROTECTION 10
> 
> It may be re-named to PROT_LIST_LEN later, probably.
> 
> How does this plan sound to you?
> 

These three constants are the part of the whole Wear-leveling algorithm,
not only for the protection tree/lists. especially for the GET mothed. 
As far as I could see, Different type data should protect different
'time'. protection 'time' classification makes sense. By means of the
classification, we can implement some more improvement, for instance:

1. UBI_LONGTERM data's PEB may not be protected, but insert into the
USED RB-tree directly, whereas other type data should do.

2. We may split the @dtype into more sub-type. Take the UBI_UNKNOWN as
an example, it seems to have many UBI_UNKNOWN type date in the current
UBI/UBIFS implementation. We may be able to dynamic evaluate the real
type of these UBI_UNKNOWN data in the EBA Sub-system and then GET more
optimal PEB, although this seems to be not so easy.

fundamentally, the question, in my opinion, is not one or three
constants, but how much 'time' corresponding type data should be
protected.

Listen with your suggestion. Thanks.

-- 
Yours sincerely
xiaochuan-xu(cqu.edu.cn)