[LinuxBIOS] wiki access and commit rights

[Carl-Daniel Hailfinger]

Hi,

is there any process to get commit rights or are they only
reserved for a core team? I'd like to work on integrating
lzma compression support in the following weeks. After that,
I plan to add support for a few SuperIO chips found on
Asus boards.

Regards,
Carl-Daniel

[Stefan Reinauer]

* Carl-Daniel Hailfinger  [060523 15:29]:
> Hi,
>
> is there any process to get commit rights or are they only
> reserved for a core team? I'd like to work on integrating
> lzma compression support in the following weeks. After that,
> I plan to add support for a few SuperIO chips found on
> Asus boards.

The process has been very simple so far. Developers start out by 
sending patches to this list, so the work can be discussed and 
reviewed.

When developers start contributing on a regular basis and their
contributions are free of big issues in their reviews we add a
commit account.

We're not trying to scare people away, but as firmware is a very fragile
thing we are trying to establish a feeling for the necessary caution.

This has been done informally so far, but we are going to have the
development process and coding guidelines formalized and written down
soon.

Regards,
Stefan

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> Carl-Daniel Hailfinger  [060523 15:29]:
> > Hi,
> >
> > is there any process to get commit rights or are they only
> > reserved for a core team? I'd like to work on integrating
> > lzma compression support in the following weeks. After that,
> > I plan to add support for a few SuperIO chips found on
> > Asus boards.
>
> The process has been very simple so far. Developers start out by 
> sending patches to this list, so the work can be discussed and 
> reviewed.

OK, then I'll continue sending patches to the list.
Would you be so kind and review the patches I sent today and tell me
what to make better? Thanks!
> We're not trying to scare people away, but as firmware is a very fragile
> thing we are trying to establish a feeling for the necessary caution.

I'm already trying to be careful because of my kernel development
background, but I understand firmware requires even more caution.

Regards,
Carl-Daniel

[Ronald G Minnich]

Carl-Daniel Hailfinger wrote:
> Stefan Reinauer wrote:
> > Carl-Daniel Hailfinger  [060523 15:29]:
> > > Hi,
> > >
> > > is there any process to get commit rights or are they only
> > > reserved for a core team? I'd like to work on integrating
> > > lzma compression support in the following weeks. After that,
> > > I plan to add support for a few SuperIO chips found on
> > > Asus boards.
> >
> > The process has been very simple so far. Developers start out by 
> > sending patches to this list, so the work can be discussed and 
> > reviewed.
>
> OK, then I'll continue sending patches to the list.
> Would you be so kind and review the patches I sent today and tell me
> what to make better? Thanks!

Please, please make sure when you send a patch you have tested with a 
abuild.

Stefan, I recently found a build problem that only cropped up with 
maximum log levels set to 9. Can we have a Config.abuild in each target 
directory with "all options on"? How do we cover this?

thanks, Carl-Daniel, for your understanding and patience. I am glad we 
have another linuxbios hacker coming on board!

ron

[Stefan Reinauer]

* Ronald G Minnich  [060523 18:45]:
> Please, please make sure when you send a patch you have tested with a 
> abuild.

Yes, this helps a lot. We have seriously been considering to
automatically block patches that break builds in the tree automatically.

The reason we didnt was basically the time it takes to compile all
boards, and decoupling the processes to work concurrently hasnt been
done due to lack of time.
> Stefan, I recently found a build problem that only cropped up with 
> maximum log levels set to 9. Can we have a Config.abuild in each target 
> directory with "all options on"? How do we cover this?

Defining "on" with non-boolean values can be tricky ;-) We can go and 
compile everything with 9, then 8, then 7, ... and see where it starts
working.

I remember with the agami/aruma the reason I tried to push CAR is
because romcc would compile something like 10-20 minutes before you get
an error message that you are running out of registers.

Should we just force this low by setting ASM_CONSOLE_LOGLEVEL here?

So the question is: How do we want to cope with a board that compiles
with 8 but not with 9. Is this broken? Or would it be smart to say "this is
so complex it will never work with more than 8"?

Stefan

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> Ronald G Minnich  [060523 18:45]:
> > Please, please make sure when you send a patch you have tested with a 
> > abuild.
>
> Yes, this helps a lot. We have seriously been considering to
> automatically block patches that break builds in the tree automatically.
>
> The reason we didnt was basically the time it takes to compile all
> boards, and decoupling the processes to work concurrently hasnt been
> done due to lack of time.

We still could check after the fact and mail the blame to this list.
Hm. I just hacked together a logfile analyzer. What about such a log:

New in revision 2303:
New in revision 2304:
New in revision 2305:
New in revision 2306:
New in revision 2307:
 Processing mainboard/broadcom/blast (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x500f): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/broadcom_blast/normal'
+make: *** [normal/linuxbios.rom] Error 1

Processing mainboard/tyan/s2735 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x1e7f): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2735/normal'
+make: *** [normal/linuxbios.rom] Error 1

Processing mainboard/tyan/s2891 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x32e3): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2891/normal'
+make: *** [normal/linuxbios.rom] Error 1

Processing mainboard/tyan/s2895 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x350b): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2895/normal'
+make: *** [normal/linuxbios.rom] Error 1

New in revision 2308:
New in revision 2309:
New in revision 2310:

Regards,
Carl-Daniel

[Ronald G Minnich]

Carl-Daniel Hailfinger wrote:
> Stefan Reinauer wrote:
> > Ronald G Minnich  [060523 18:45]:
> > > Please, please make sure when you send a patch you have tested with a 
> > > abuild.
> >
> > Yes, this helps a lot. We have seriously been considering to
> > automatically block patches that break builds in the tree automatically.
> >
> > The reason we didnt was basically the time it takes to compile all
> > boards, and decoupling the processes to work concurrently hasnt been
> > done due to lack of time.
>
> We still could check after the fact and mail the blame to this list.
> Hm. I just hacked together a logfile analyzer. What about such a log:

sure. this is a low-traffic list. I think letting people see the errors 
might be useful.

comments?

ron

[Ronald G Minnich]

Stefan Reinauer wrote:
> So the question is: How do we want to cope with a board that compiles
> with 8 but not with 9. Is this broken? Or would it be smart to say "this is
> so complex it will never work with more than 8"?

my problem was simpler. A debug print used a variable that was only 
defined in the romcc world. It was a simple problem. But it only showed 
up when the debug print was enabled.

ron