[U-Boot] livetime of boards

[Heiko Schocher]

Hello Wolfgang,

Am 08.11.2013 07:20, schrieb Wolfgang Denk:
> Dear Heiko,
>
> In message<527C767D.3070700 at denx.de>  you wrote:
>>
>>> Yes, this is perfectly fine.  I just want to allow this at _any_ time,
>>> not only once per release (near the end of the release cycle).
>>> especially for releases where bigger changes get merged it may be
>>> precious information to know when the code stopped working.
>>
>> With "once", I only meant, we once update the "livetimer" and collect
>> all the time test reports!
>
> But with your suggestion, the only stoprage for such information is
> the life timer entry in the boards.cfg file.   Or would you suggest to
> store additional information elsewhere?  Then we don't need the (then
> redundant) counter in  boards.cfg ...

Yes, if we store more information then the "livetime", we need another
approach. But with storing this somewhere else, we must take care that
the number and names of the boards in the external database are in
sync with the boards in mainline.

>>> Well, one reason is efficiency.  If the code builds fine, and does not
>>> cause efforts druing any of the ongoing work, it is more efficient to
>>> just keep it than to actively remove it, which would require active
>>> work.  I. e. I want to reduce the work load on the maintainer(s) such
>>> that they only have to become active if such action saves even more
>>> effort.  Actually it may even seem more efficient in some cases to
>>> perform minor fixing even of unmaintained boards than to remove them.
>>
>> But in the long term I think, we have more work with old, unmaintained
>> boards, then removing it. And if we remove boards actively, we maybe
>
> YOu misunderstand.  My intention is to keep them as long as they do
> NOT cause any efforts.  If they do, they are candidates for checking
> for removal.

Ah, ok!

>> force more the board maintainers (for examples corporates who have
>> interest that the board stays in mainline) to really test them ;-)
>
> Yes, but you organize more work for all of us.

That would be bad.

>>> But should we not also try to minimize efforts, especially on the
>>> custodians?  If a board does not cause any trouble, we should not have
>>> to invent additional efforts for it.
>>
>> Hmm... I am not really sure, if it is more work for removing a
>> board or fixing compiling issues ...
>
> If we have to fix compilation issues, that means that the board _IS_ a
> candidate for removal.  I suggested to keep them as long as they do
> "not cause any trouble" !

Ok, got it, that sounds good. So, if we introduce new features we
have to check for boards which are affected:

- board is in maintained state -> convert to new feature
- board is in unmaintained state -> drop it ...

>>> I don't really understand this argument. The I2C code is either
>>> hardware independent (say, the command line interface code), or it is
>>> platform specific (say, the driver code for the I2C controller on a
>>> specific SoC), or it is board dendent (say, some specific twiddeling
>>> with I2C devices to perform some magic operations on a board).
>>>
>>> In the first two cases the work wil have to be done in any case
>>> (except for the realy rare case that there are only old, unmaintained
>>> boards left using this SoC).  An for the board specific code you can
>>   >
>>> check if you need to adapt it by checking the board's test status.  If
>>> the board is unmaintained, then we enter the "it hurts" branch, and
>>> drop the board.
>>
>> Hmm... :
>>
>> pollux:u-boot hs [master] $ grep -lr HARD_I2C arch/powerpc/
>> [...]
>> arch/powerpc/cpu/mpc8xx/i2c.c
>> [...]
>> arch/powerpc/cpu/mpc8260/i2c.c
>> arch/powerpc/cpu/mpc5xxx/i2c.c
>> arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c
>> arch/powerpc/cpu/mpc512x/i2c.c
>> pollux:u-boot hs [master] $
>
> THi sis all architecure support.  None of these files are board
> specific.  None of them would be removed if you crap old boards.

Hmm.. a U-Boot rule is, remove unnused code, or? If we remove all
boards, who use this drivers, we remove the drivers also ...

>> Is it worth to move the drivers to drivers/i2c/ and convert them to
>> the new framework? Or is it better to delete them and the boards,
>> which use them ... Ok, if we had such a "livetimer" without deleting
>> old boards, you are right, I could do now:
>
> How do you know which boards use these drivers?

I must find out ...

>> - search the boards, which use the drivers
>> - search the state of this board
>> - decide, dropping or convert ...
>>     On which criteria whould this decision be done? I have no idea
>>     if this boards exist anymore ...
>
> There is no conflict with what I wrote - if you can find that only
> "old" boards are using these drivers, then both the boards and the
> drivers are candidates for removalk.  But you need to find this
> correlation first, and verify that there are no "good" boards left
> that use trhem do.

Yes.

But there is a difference! With having old boards in mainline, I must
do the above step "search the state, and decide what to do". With
having only "good" boards in mainline, I do not need this steps.

But I aggree with you, if we have the rule:
"unmaintained board and compile error" -> remove it

This decision is easy and I am fine with it.

> All of this is totally different of the mechanism how to determine
> what are "good" or "old" boards.
>
>> If we have only good boards, I have only one way ->  convert. No
>> time wasted for the above steps ...
>
> It does not really matter when you have to check if there are "good"
> users of this code left.  You have to do this in both cases - either
> when removing the boards automatically, or when touching that code.
>
> With your solution, you will probably have to do it twice, as you
> cannot be really sure that the guy who removed the board support
> verified that he was the last user of some global architecture support
> code.

Yes for the driver code. As I said in this discusion, removing boards
is no trivial job.

>> I dislike additional efforts too (But the question is, needs removing
>> old boards more effort than fixing them all the time maybe uselessly?).
>
> Can you please re-read what I wrote?  I say we keep them as long as
> they do NOT need ANY fixing.  If they do, this is a toalluy new game.

I got it now ;-)

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany