[RFC] newbuild branch

[Patrick Georgi]

Hi,

As some of you might have noticed, there is a coreboot-v2-newbuild
branch in the repository. It contains the current state of an effort to
get coreboot v2 to build under kconfig/kbuild(-style) tools, which seems
to be universally accepted as a desirable goal.
(If you don't think so, please state your issues with that, so we
wouldn't waste too much time on this, kthx)

That work was done in a way that abuild is unaffected: except some minor
remaining issues with CONFIG_* prefixes, the source files are exactly
the same as upstream, and abuild ran successfully.
Two boards are Kconfig'd so far, QEmu and Kontron 986LCD-M, but there
are some remaining issues with the Kontron, so it doesn't boot yet. QEmu
builds and runs (but without CAR at this time, and that's deliberate to
have a test case for a romcc-board)

There are quite a lot of things to be done still, and many things are
not at the right location yet (eg. many configuration options reside in
src/Kconfig when there's a better place for them).
Should we push it to trunk now (given that it doesn't break abuild)?
Should we define a milestone that has to be completed (eg. a given set
of boards has to run)?

This is a request for comments, so... :)

Thanks,
Patrick

[Myles Watson]

> are some remaining issues with the Kontron, so it doesn't boot yet.
> QEmu
> builds and runs (but without CAR at this time, and that's deliberate to
> have a test case for a romcc-board)

I like the idea of having a test case representing each large subset of
supported boards.
> There are quite a lot of things to be done still, and many things are
> not at the right location yet (eg. many configuration options reside in
> src/Kconfig when there's a better place for them).

I think that can be refined later, but the better it is organized, the
easier it will be to port boards to the new setup.
> Should we push it to trunk now (given that it doesn't break abuild)?
> Should we define a milestone that has to be completed (eg. a given set
> of boards has to run)?

For major changes like this, I'd like to see Qemu, Serengeti-cheetah, one
Intel board, 1 AMD K8 or Fam10 board, and maybe a Geode board functional
before committing.  I think that forces some of the kinks to be worked out
earlier.

Thanks,
Myles

[ron minnich]

On Thu, Jul 30, 2009 at 1:15 PM, Myles Watson wrote:
> For major changes like this, I'd like to see Qemu, Serengeti-cheetah, one
> Intel board, 1 AMD K8 or Fam10 board, and maybe a Geode board functional
> before committing.  I think that forces some of the kinks to be worked out
> earlier.

So we keep working on the branch, I suppose, but then we do need some
people to take ownership of a board. I'd really like to have this in
upstream by 9/9/9.

BTW I do have a romcc-free branch that also implements seperate
compilation (no more included .c files). We decided to let this wait
until Kconfig goes in.

thanks

ron

[ron minnich]

On Thu, Jul 30, 2009 at 1:15 PM, Myles Watson wrote:
> For major changes like this, I'd like to see Qemu, Serengeti-cheetah, one
> Intel board, 1 AMD K8 or Fam10 board, and maybe a Geode board functional
> before committing.  I think that forces some of the kinks to be worked out
> earlier.

Myles, if we can guarantee that everything keeps working, i.e. there
is no harm done with Kconfig in the tree, is there any reason not to
start comitting this Kconfig code?

This is how we made the change rom v1 config tool to v2 config tool;
they were both active in the v2 tree at the same time, and gradually
the v1 config tool died out.

ron

[Myles Watson]

> On Thu, Jul 30, 2009 at 1:15 PM, Myles Watson wrote:
> > For major changes like this, I'd like to see Qemu, Serengeti-cheetah,
>
> one
> > Intel board, 1 AMD K8 or Fam10 board, and maybe a Geode board functional
> > before committing.  I think that forces some of the kinks to be worked
>
> out
> > earlier.
>
> Myles, if we can guarantee that everything keeps working, i.e. there
> is no harm done with Kconfig in the tree, is there any reason not to
> start comitting this Kconfig code?

The only harm is that we have multiple half-done things in the tree right
now.  I think it makes the whole project more fragile to leave the loose
ends.
> This is how we made the change rom v1 config tool to v2 config tool;
> they were both active in the v2 tree at the same time, and gradually
> the v1 config tool died out.

I think you're right; it can work out.  I guess that's why v2 config is
still called newconfig.

Thanks,
Myles

[ron minnich]

On Fri, Jul 31, 2009 at 11:17 AM, Myles Watson wrote:
> I think you're right; it can work out.  I guess that's why v2 config is
> still called newconfig.

yes

ron

[Stefan Reinauer]

On 7/31/09 8:17 PM, Myles Watson wrote:
> > This is how we made the change rom v1 config tool to v2 config tool;
> > they were both active in the v2 tree at the same time, and gradually
> > the v1 config tool died out.
>
> I think you're right; it can work out.  I guess that's why v2 config is
> still called newconfig.

Well, yeah, the transition wasn't ever finished, and we're doing another
one on top now.. This _is_ scary. Let's have something that works before
we mess our good tree up.

Stefan

[Stefan Reinauer]

On 7/31/09 8:11 PM, ron minnich wrote:
> Myles, if we can guarantee that everything keeps working, i.e. there
> is no harm done with Kconfig in the tree, is there any reason not to
> start comitting this Kconfig code?

Yes. It's not good for much yet. Just adding half-finished stuff makes
the code quality decrease.

Or, differently asked: Is there any benefit if we merge before it is
done? Merging when it is done is somewhat the purpose of going through
this concept of merging instead of just committing to a single tree.
> This is how we made the change rom v1 config tool to v2 config tool;
> they were both active in the v2 tree at the same time, and gradually
> the v1 config tool died out.

Well, the problem is missing momentum - and that does not come from
merging. There was momentum when v1 was switched to v2.

Stefan