[U-Boot] [ANNOUNCE] Kconfig support

[Ladislav Michl]

Hello Heiko!

On Wed, Apr 22, 2009 at 10:53:46AM +0200, Heiko Schocher wrote:
> Hello Ladislav
> 
> Ladislav Michl wrote:
> > May I? Last time I looked at mainline U-Boot about year ago, sending few
> > patches and it was working for me. Since then some changes (only minor ones
> > from design pespective) were applied (some of them automatically with some
> > scripts) and since then my board support was broken. It cannot boot neither
> > from network - network code uses get_timer and I bet _no_ OMAP based will get
> > IP address from my DHCP server sitting behind ancient hub - (still true and so
> > far no comments except from Dirk) nor from NAND (already fixed). And once
> > AT91RM9200 landed on my table I needed to patch other AT91RM9200 based boards
> > just because they suffered the same problems I meet. Obviously noone noticed
> > for years. Thats from my perspective too much breakage such a "cosmetic"
> > changes. And what if we try to do any fundamental one?
> > 
> > Based on this experience I wouldn't expect much of those 200 boards to work
> > properly. Or was it only my bad luck? To sum this up: wide majority of boards
> > is just sitting in tree, without any interest. It compiles so it must be good,
> > right? Switching v1 into maintenance mode only makes sense as well, it is just
> 
> What else should a maintainer do? He have not all boards to try the
> new code! You can just look at Coding Style, clean compile and maybe
> he see, that this Code couldn;t work ...

That's perfectly understandable. I'm just trying to point out, that
"design flaws can be fixed incrementaly, without breaking anything"
attitude does not reflect reality. We break stuff and noone can test
for all boards, so the real question is acceptable level of breakage
we have to suffer from before deciding to try another approach. Just
imagine amount of changes needed, amount of changes done over last year,
amount of boards maintainers care about their board support since they
pushed them into mainline and ask yourself a question how many boards
can survive each such a change still functional. All the long time this
slow evolution will happening, we will pretending ourselves that
we did not break anything and everyone is happy.

> To look, that a board works with actual code is at least the job
> from the boardmaintainers, and if they notice that some code no
> longer works, they have to post patches which fixes that... whats
> wrong with that?

Nothing, were did I express the opposite? I'm not whining anyone for
breaking anything, just trying to honestly describe situation I had to
face.

> > matter of decision. And you obviously decide to incrementaly fix v1. So there
> > really is nothing to discuss.
> > 
> > Now given the fact that most board support consist of config file
> > and few lines of board specific glue code, the idea of doing major
> > architectural changes in v2 and migrating board support there doesn't
> > look completely wrong, does it? Of course, if v1 "just works" for simple
> > designs there is no need to throw it away, but I perfectly understand
> > Sergey Kubushyn despair trying to support more devices of the same kind.
> 
> I can speak here only for the i2c subsystem. Sergey posted patches which
> where from the design "nearly" perfect, but this doesn;t gone in main-
> line because missing CodingStyle fixes, Patches in not a "good Style"
> and so on ... and there were 2-3 minimal points we couldn;t arrange :-(
> And someday he went away, because his time was over (no more money
> for it) ... :-( This way open source did not work! We cannot plonk
> some patches (which change design) to the mailinglist and ignore
> all comments, and if they not go in mainline blackguard actual code!
> 
> And so we stand here ... (I try to forward this design in my freetime,
> but this is a rare resource ...)

Yup, and I hereby point to amount of work Pengutronix already did for us.

> So I opened 2 branches in u-boot-i2c.git to compare the 2 "suggestions"
> for the multibus approach in the i2c subsystem, so we have a real base
> for discussion.

And we have v2 as a real base for discusion as well and I have bad feeling
that not many people actually looked at v2 code. Its whole design reflects
"multibus approach" and adding i2c here is quite an easy (but time consuming,
of course) task.

> But no one seems to have interest in this :-(

Understandable, clean design does not show up on itself. Most embedded people
hack until it works and then it's done. They are (myself including) payed to
work exactly this way. How would I explain my boss that I spent significant
amount of time designing anything we could live happily without for at least
one year? (doable, but... ) Although situation improved a lot over last few
years. Again, see what is already done in v2. Let's see how many effort will
cost migration to Kconfig and remember how many effort did cost OBJ-y makefile
approach. And all this is fun comparing to driver model conversion.

> And I have hope, that this multibus design can be adapted for other
> subsystems too ... but somebody have to do this work, and if this
> is in v1, he has to do this for all boards!

Sure, therefore I suggested to put v1 to maintenence only mode and add new
board support into v2. Actually there is much more to do before for example
mips board can be added or before you can boot from MMC card, but the real
question is whenever changing all boards in v1 to use "multibus design" is
worth dealing with. After all, existing boards ships with u-boot, so it must
do its job well. And with respect to this fact even if we put v1 info feature
freeze mode, time spent with it till now would not be wasted at all. Just look
now many boards it served well! And still serves, because most board ships with
U-Boot version initially ported for them till the end of production. But if
decision is to support v1 till the end of ages in hope its design flaws will be
fixed over time I'm perfectly fine with that. I just do not believe this is
anywhere close to happen in finite time. After all the only possible solution
is to let individual developers to decide which approach is closer to their
hearts. And I'm already decided.

Best regards,
	ladis