Firewire help, please...

[Derick Centeno]

OK Dylan let's plow on!

On Apr 18, 2005, at 2:41 PM, Dylan wrote:

> Derick,
>
> I went through the kernel docs and then attempted to compile a custom 
> kernel.  I am using the stock kernel (2.4.20-8d...) that came with 
> YDL.  I first tried my own custom config and when I compiled it, I got 
> an error:
>
> make[1]: Entering directory 
> `/usr/src/linux-2.4.20-8d/arch/ppc/platforms'
> make all_targets
> make[2]: Entering directory 
> `/usr/src/linux-2.4.20-8d/arch/ppc/platforms'
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-8d/include -Wall 
> -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing 
> -fno-common -fomit-frame-pointer -I/usr/src/linux-2.4.20-8d/arch/ppc 
> -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized 
> -mmultiple -mstring   -nostdinc -iwithprefix include 
> -DKBUILD_BASENAME=pmac_pic  -c -o pmac_pic.o pmac_pic.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-8d/include -Wall 
> -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing 
> -fno-common -fomit-frame-pointer -I/usr/src/linux-2.4.20-8d/arch/ppc 
> -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized 
> -mmultiple -mstring   -nostdinc -iwithprefix include 
> -DKBUILD_BASENAME=pmac_setup -I/usr/src/linux-2.4.20-8d/drivers/scsi 
> -I/usr/src/linux-2.4.20-8d/fs/partitions 
> -I/usr/src/linux-2.4.20-8d/arch/ppc/mm -c -o pmac_setup.o pmac_setup.c

The compiler is telling you exactly what the problem is right here!
> pmac_setup.c:675:44: macro "set_task_state" requires 2 arguments, but 
> only 1 given
> pmac_setup.c: In function `pmac_discover_root':
> pmac_setup.c:675: `set_task_state' undeclared (first use in this 
> function)
> pmac_setup.c:675: (Each undeclared identifier is reported only once
> pmac_setup.c:675: for each function it appears in.)
In short, line 675 of the program called pmac_setup.c is the culprit.  
Because this is completely open source you can write your own 
correction to the code which here just means that you need to declare 
the function set_task_state and that is it!  Until another error is run 
into.  Of course, you really should know the C language very well and 
understand what you are declaring.  If a function is unnecessary for 
your needs you could just comment it out, and then the compiler would 
compile the program picking up from where it left off, but again do you 
know enough C to read and understand what the code is doing or for that 
matter what it should NOT be doing?

This is one of those uncomfortable situations where either one knows or 
one doesn't and any other position is a waste of time.  You could 
perhaps avoid this problem (to an extent) by choosing a kernel's source 
which is more current.  I found the early 2.6 series quite robust and 
reliable.  And far less buggy, which is really the whole point.

The modules which you may be looking to implement or utilize should be 
available at a higher kernel version than 2.4.20-8d and written better 
to boot (excuse the pun).

Remember that the module packages are themselves built up from just the 
same kind of code as whatever is in pmac_setup.c and if you see that 
kind of report from the compiler again understand that it (the 
compiler) is beckoning (calling upon your attention) so that you to 
correct it.  It is assuming that you are a programmer it can seek help 
from; so find your inner C programmer and do what you can OR you could 
play it a bit more clever and find kernel source closer to what is 
current.

A bit of a hint ... programmers tend to work nearly universally on what 
is interesting and what is interesting (calling and demanding their 
full attention) is whatever is current.  As a project becomes more and 
more associated with the past, the less importance that project has and 
the less of a return or utility, you as a user of that software will 
likely benefit from.  This means that kernels of the 2.4 and 2.3  and 
earlier series are less likely to see any substantive correction, 
repair or change other than whatever you yourself make which of course 
you are obligated to clearly note and post for others via comments 
within the source (as well as notifying the software team of whatever 
changes you made) to review according to the GPL.

I ran into the same problem as you did sometime ago, and rewrote some 
kernel code also.  I corrected errors similar to what you discovered 
and other declaration error problems such as confusion of type and so 
on.  I do recall eventually following the advice I'm suggesting to you 
and moving up to a more current kernel version (then 2.6.x).

Best wishes....