Can one build 2.5.68 with allyesconfig?

Is anyone else able to build 2.5.68 with allyesconfig?

I'm using RH7.2, so the first thing I did was edit the main Makefile to replace gcc with "gcc3" (3.0.4). Maybe the compiler is STILL my problem. The problem doesn't stand out clearly to me, but I also haven't put much thought into it. I'll try to use some more of my brain. But if it's not going to be fixable by me, I humbly request help.

Before the compile terminates, there are a number of the same warning for other files, being the same as the ones below for 'flags'.

The compile dies thusly:

gcc3 -Wp,-MD,drivers/char/.riscom8.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DKBUILD_BASENAME=riscom8 -DKBUILD_MODNAME=riscom8 -c -o drivers/char/.tmp_riscom8.o drivers/char/riscom8.c
In file included from drivers/char/riscom8.c:51:
drivers/char/riscom8.h:88: field tqueue' has incomplete type drivers/char/riscom8.h:89: field tqueue_hangup' has incomplete type drivers/char/riscom8.c:84: warning: type defaults to int' in declaration of DECLARE_TASK_QUEUE' drivers/char/riscom8.c:84: warning: parameter names (without types) in function declaration drivers/char/riscom8.c: In function `rc_init_CD180':
drivers/char/riscom8.c:247: warning: implicit declaration of function save_flags' drivers/char/riscom8.c:247: warning: implicit declaration of function cli' drivers/char/riscom8.c:251: warning: implicit declaration of function sti' drivers/char/riscom8.c:264: warning: implicit declaration of function restore_flags' drivers/char/riscom8.c:245: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_mark_event':
drivers/char/riscom8.c:351: warning: implicit declaration of function queue_task' drivers/char/riscom8.c:351: tq_riscom' undeclared (first use in this function) drivers/char/riscom8.c:351: (Each undeclared identifier is reported only once drivers/char/riscom8.c:351: for each function it appears in.) drivers/char/riscom8.c:352: warning: implicit declaration of function mark_bh' drivers/char/riscom8.c:352: RISCOM8_BH' undeclared (first use in this function) drivers/char/riscom8.c: In function `rc_receive_exc':
drivers/char/riscom8.c:435: structure has no member named tqueue' drivers/char/riscom8.c:435: tq_timer' undeclared (first use in this function) drivers/char/riscom8.c: In function `rc_receive':
drivers/char/riscom8.c:466: structure has no member named tqueue' drivers/char/riscom8.c:466: tq_timer' undeclared (first use in this function) drivers/char/riscom8.c: In function `rc_check_modem':
drivers/char/riscom8.c:556: warning: implicit declaration of function schedule_task' drivers/char/riscom8.c: In function rc_setup_port':
drivers/char/riscom8.c:870: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_open':
drivers/char/riscom8.c:1090: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_close':
drivers/char/riscom8.c:1134: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_write':
drivers/char/riscom8.c:1227: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_put_char':
drivers/char/riscom8.c:1303: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_flush_chars':
drivers/char/riscom8.c:1325: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_flush_buffer':
drivers/char/riscom8.c:1368: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_get_modem_info':
drivers/char/riscom8.c:1388: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_set_modem_info':
drivers/char/riscom8.c:1408: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_ioctl':
drivers/char/riscom8.c:1446: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c:1446: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c:1467: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_throttle':
drivers/char/riscom8.c:1582: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_unthrottle':
drivers/char/riscom8.c:1605: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_stop':
drivers/char/riscom8.c:1628: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_start':
drivers/char/riscom8.c:1646: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function rc_set_termios':
drivers/char/riscom8.c:1703: warning: flags' might be used uninitialized in this function drivers/char/riscom8.c: In function do_riscom_bh':
drivers/char/riscom8.c:1725: warning: implicit declaration of function run_task_queue' drivers/char/riscom8.c:1725: tq_riscom' undeclared (first use in this function) drivers/char/riscom8.c: In function `rc_init_drivers':
drivers/char/riscom8.c:1754: warning: implicit declaration of function init_bh' drivers/char/riscom8.c:1754: RISCOM8_BH' undeclared (first use in this function) drivers/char/riscom8.c: In function `rc_release_drivers':
drivers/char/riscom8.c:1833: warning: implicit declaration of function remove_bh' drivers/char/riscom8.c:1833: RISCOM8_BH' undeclared (first use in this function) drivers/char/riscom8.c:1829: warning: `flags' might be used uninitialized in this function drivers/char/riscom8.c: At top level:
drivers/char/riscom8.c:84: warning: DECLARE_TASK_QUEUE' declared static' but never defined make[2]: *** [drivers/char/riscom8.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

1) I think the 3.0.4 compiler had some issues - 3.2.2 may be a better idea.

2) allyesconfig is probably NOT able to build an actual kernel that will work - in particular, there are a number of pairs/sets of drivers that are mutually exclusive for a given device. And as you noticed, allyesconfig will try to build stuff that's known to be b0rken.

3) Even if it works, it will be a huge kernel with lots of stuff you almost certainly don't need (got an ISDN card? I didn't think so ;). You would more likely want to customize the kernel for what you need, or at least consider using 'allmodconfig' so you can insmod the parts you need and skip the rest.

Great. Why do I have a feeling that installing it will bork my workstation? Not to say that it can't be done but that I will probably screw it up. I'm sure that Red Hat (7.2) has some dependencies on there being 2.96 installed. Any suggestions on how I might deal with this problem?

I'm not actually going to run the kernel.

I'm trying to do an allyesconfig kernel so that I can get all printk format strings.

On Tue, 22 Apr 2003 16:41:18 -0400 [email protected] wrote:

| On Tue, 22 Apr 2003 16:49:03 EDT, Timothy Miller <[email protected]>  said:
| > Is anyone else able to build 2.5.68 with allyesconfig?
| > 
| > I'm using RH7.2, so the first thing I did was edit the main Makefile to 
| > replace gcc with "gcc3" (3.0.4).  Maybe the compiler is STILL my 
| >
| 
| 1) I think the 3.0.4 compiler had some issues - 3.2.2 may be a better idea.
| 
| 2) allyesconfig is probably NOT able to build an actual kernel that will
| work - in particular, there are a number of pairs/sets of drivers that are
| mutually exclusive for a given device. And as you noticed, allyesconfig
| will try to build stuff that's known to be b0rken.
| 
| 3) Even if it works, it will be a huge kernel with lots of stuff you almost
| certainly don't need (got an ISDN card? I didn't think so ;).  You would more
| likely want to customize the kernel for what you need, or at least consider
| using 'allmodconfig' so you can insmod the parts you need and skip the rest.

After you weed out the 50 or so drivers that won't compile (disable them), you'll end up with a kernel that is way to big to boot.
I did this about 2 months ago and posted the results to lkml.

But it's a good build-only tool.

--
~Randy

Well...

Then the use of 3.0.2 won't matter..

'make -k' should suffice there. I assume you're grovelling them out of the .o files? Otherwise, just grepping the *.c should be OK.

Also, note that you probably want to *also* do an 'allmodconfig' just in case there's printk inside a #ifdef MODULE....

[SNIPPED...]

drivers/char/riscom8.c uses old methods including 'cli' and 'sti'. It hasn't been fixed yet. Remove this from your configuration and try again.

No code should use cli and sti. If any compile errors out on 2.5.n.n, as a result of this, and you need the driver, you might try to inspect the source and contact its maintainer. There are a lot of cleanups on-going in this version.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

John Cherry has a nice set of pages covering the compile status, including allyesconfig IIRC.

See http://www.osdl.org/archieve/cherry/stability
Hmmm, result in 404 right now???

Sam

On Tue, 22 Apr 2003 23:08:34 +0200 Sam Ravnborg <[email protected]> wrote:

| On Tue, Apr 22, 2003 at 04:49:03PM -0400, Timothy Miller wrote:
| > Is anyone else able to build 2.5.68 with allyesconfig?
| 
| John Cherry has a nice set of pages covering the compile status,
| including allyesconfig IIRC.
| 
| See http://www.osdl.org/archieve/cherry/stability
| Hmmm, result in 404 right now???

Use "archive" and I think it will work for you.

--
~Randy

Scanning .o files gets things which are not printk format strings. Grepping .c files doesn't get macros. The only choice is to produce .i files.

What will get the greater coverage? There seem to be some things that don't get 'y' or 'm' in .config when you do an allmodconfig.

No, of course not. But I can give you a .config that comes very close on i386. Resulting vmlinux is 28MB, so this shouldn't boot.

It was created for 2.5.67 with allyesconfig and manual weedout, then updated to 2.5.68.

Jörn

Geld macht nicht glücklich.
Glück macht nicht satt.

As mentioned in other mail, compile statistics for the latest 2.5 kernels are at: http://www.osdl.org/archive/cherry/stability/

However, these statistics are based on defconfig and allmodconfig builds (not allyesconfig). The allmodconfig build contains the riscom8 errors that you have observed as well as most other warnings/errors you would find in an allyesconfig build.

I have also compiled a list of cli/sti removal candidates. The files that flag cli/save_flags conversions are:

===========================================
cli, save_flags conversions: 66 files
===========================================
drivers/atm/ambassador.c
drivers/atm/uPD98402.c
drivers/atm/zatm.c
drivers/cdrom/cdu31a.c
drivers/cdrom/cm206.c
drivers/cdrom/sbpcd.c
drivers/cdrom/sonycd535.c
drivers/char/cyclades.c
drivers/char/epca.c
drivers/char/esp.c
drivers/char/ftape/lowlevel/fdc-io.c
drivers/char/ftape/lowlevel/ftape-calibr.c
drivers/char/ftape/lowlevel/ftape-format.c
drivers/char/generic_serial.c
drivers/char/ip2main.c
drivers/char/isicom.c
drivers/char/istallion.c
drivers/char/moxa.c
drivers/char/mxser.c
drivers/char/rocket.c
drivers/char/stallion.c
drivers/i2c/i2c-elektor.c
drivers/isdn/act2000/capi.h
drivers/isdn/divert/divert_init.c
drivers/isdn/divert/divert_procfs.c
drivers/isdn/divert/isdn_divert.c
drivers/isdn/hardware/avm/b1.c
drivers/isdn/hardware/avm/c4.c
drivers/isdn/hardware/avm/t1isa.c
drivers/isdn/hysdn/boardergo.c
drivers/isdn/hysdn/hysdn_proclog.c
drivers/isdn/hysdn/hysdn_sched.c
drivers/isdn/i4l/isdn_audio.c
drivers/isdn/i4l/isdn_tty.c
drivers/isdn/i4l/isdn_ttyfax.c
drivers/isdn/icn/icn.c
drivers/isdn/isdnloop/isdnloop.c
drivers/isdn/pcbit/edss1.c
drivers/isdn/pcbit/layer2.c
drivers/isdn/sc/command.c
drivers/isdn/sc/message.c
drivers/isdn/sc/shmem.c
drivers/isdn/sc/timer.c
drivers/net/3c527.c
drivers/net/82596.c
drivers/net/hamradio/6pack.c
drivers/net/hamradio/dmascc.c
drivers/net/hamradio/mkiss.c
drivers/net/irda/toshoboe.c
drivers/net/ni5010.c
drivers/net/ni65.c
drivers/net/pcmcia/fmvj18x_cs.c
drivers/net/pcmcia/nmclan_cs.c
drivers/net/sk_mca.c
drivers/net/tulip/xircom_tulip_cb.c
drivers/net/wan/comx-hw-comx.c
drivers/net/wan/comx-hw-locomx.c
drivers/net/wan/comx-hw-mixcom.c
drivers/net/wan/comx.c
drivers/net/wan/sdla.c
drivers/net/wan/sdla_x25.c
drivers/net/wan/x25_asy.c
drivers/scsi/AM53C974.c
drivers/scsi/mca_53c9x.c
drivers/scsi/psi240i.c
fs/nfsd/nfs4proc.c

The complete list of porting items that I have pulled from compiler output can be found at:
http://www.osdl.org/archive/cherry/stability/linus-tree/port_items.txt

Sorry about occasional 404 problems. This is an update artifact that we are working on. Just try again.

John

Do you have any form of automation when dealing with breaking drivers? If I could reduce the necessary time for creating a working allyesconfig, that would be quite nice.

Allyesconfig has a couple of advantages. The analysis of object files is must simpler with just vmlinux to worry about. And some errors don't show up until link time, not sure if you can catch all of them with allmodconfig.

Jörn

If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack

No. I think Randy Dunlap replied earlier that he spent considerable time weeding out broken drivers from an allyesconfig configuration. This still did not result in a bootable image.

If you want to build with allyesconfig and continue on when you run into errors, just use the -k (keep going) option with make.

Agreed.

Feel free to hack on the compregress.sh script to produce compilation results that would benefit what you are doing. It lives on the stability page.

John

Yes, it takes manual inspection of some 30 failures, each costing just a minute or so. But the compile time between those really hurts, it generates many context switches for my brain.

Which may be a good thing. 28MB would have used all my memory not too long ago. :)

Good idea. Maybe that can cut down the context switches.

Will do. Thank you!

Jörn

And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong