Compile Breakage On 2.6.18-rc1-mm1

I have som problems with kernel 2.6.18-rc1-git4:

$ export KERNELPATH=/usr/src/linux-2.6.18-rc1-git4/
$ make
Checking requirements... ok.
Checking kernel configuration... ok.
make -C /usr/src/linux-2.6.18-rc1-git4/ SUBDIRS=/home/user/madwifi/svn/madwifi-0.9.2 modules
make[1]: Entering directory `/usr/src/linux-2.6.18-rc1-git4'
  CC [M]  /home/user/madwifi/svn/madwifi-0.9.2/ath/if_ath_pci.o
In file included from include/asm/system.h:4,
                 from include/asm/processor.h:18,
                 from include/asm/thread_info.h:16,
                 from include/linux/thread_info.h:21,
                 from include/linux/preempt.h:9,
                 from include/linux/spinlock.h:49,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:44,
                 from include/linux/module.h:9,
                 from /home/user/madwifi/svn/madwifi-0.9.2/ath/if_ath_pci.c:47:
include/linux/kernel.h:36:1: error: "roundup" redefined
In file included from <command line>:1:
/home/user/madwifi/svn/madwifi-0.9.2/ath/../include/compat.h:46:1: error: this is the location of the previous definition
make[3]: *** [/home/user/madwifi/svn/madwifi-0.9.2/ath/if_ath_pci.o] Error 1
make[2]: *** [/home/user/madwifi/svn/madwifi-0.9.2/ath] Error 2
make[1]: *** [_module_/user/tmp/madwifi/svn/madwifi-0.9.2] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.18-rc1-git4'
make: *** [modules] Fehler 2

The problem with kernel 2.6.18-rc1-git4 is caused by the a change in the linux kernel: linux-2.6.18-rc1-git4 # grep roundup ./include/linux/kernel.h #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y)) attribute_const roundup_pow_of_two(unsigned long x) linux-2.6.17-ck1 # grep roundup ./include/linux/kernel.h attribute_const roundup_pow_of_two(unsigned long x)

after removing roundup from compat.h everything works fine.

quick patch which fix issues with roundup macro

patch redef_roundup_patch.diff

Signed-off-by: Pavel Novák <strasak@bubakov.net>

My apologies, the error I noted was after correcting the roundup macro problem. It sounds like -mm changed something in the device driver model (again) between .17-mm1 and .18-mm1. I really don't have the time to diff and look right now, but I'll be back in a few days, with any luck ;-)

Thanks for the info, guys,

• Dave

related to #760

Applied to r1689. Thanks ignusss and co

Really fixed in r1691.

Tests for versions should be left for well established kernels and difficult cases (a function becomes a macro, changes the number of arguments etc). With -mm and -rc floating around, and before the actual release of 2.6.18, testing for the kernel being 2.6.18 or newer doesn't seem to be a good idea.

Not really fixed in r1691 ;-P

Under r1691, I still get the same compile-time error I got before (although the non-mm-related problem is now fixed, but that's not what the ticket was for): ath/if_ath.c: In function `ath_vap_create': ath/if_ath.c:1140: error: structure has no member named `class_dev' make ... ath/if_ath.o ... Error 1

It seems to me that you claim to have fixed the macro problem (as indeed you have), but my ticket was trying to focus on the error above, not the version detection nor the macro problem.

BTW - AFAICT, this ticket is totally unrelated to #760 in terms of the actual issue at hand.

Thanks again,

• Dave

BTW - I hate to SPAM the list, but if somebody has a clue how to make formatting stick (so the compiler errors I posted will actually be legible) here, please don't hesitate to fix the formatting on my posts.

Thanks for a great project, and sorry about being so annoying,

• Dave

Although you may have been trying to specify the class_dev problem, it was never described in detail on this ticket until now.

Use a group of 3 curly braces to encapsulate code snippets or output, and try the SandBox too, if all else fails. The preview button is also handy ;-)

Correction, I must have missed the class_dev stuff because it was poorly formatted. After re-reading the initial post, apologies.

The breakage is caused by gregkh-driver-network-class_device-to-device.patch in 2.6.18-rc1-mm1, which was reverted in 2.6.18-rc1-mm2 (the explanation was given as "needs work"). Description of the patch:

From: Greg Kroah-Hartman <gregkh@suse.de>
Subject: Network: convert network devices to use struct device instead of class_device

This lets the network core have the ability to handle suspend/resume
issues, if it wants to.

MadWifi accesses the "class_dev" field directly to copy the physical device information from the master device to a VAP. This is needed because there is no GET_NETDEV_DEV or COPY_NETDEV_DEV that would encapsulate access to the net_device structure.

Possible solutions would be:

1) Do nothing. We cannot anticipate for changes in the network API. Instead, we should insist that whoever changes it should also provide an easy way to extract or copy the physical device information.

2) Save the physical device data in MadWifi and get it from there. Don't rely on existence of class_dev. That's the paranoid approach. We would protect MadWifi against breakage that happened just in one -mm kernel and may never happen again.

3) Don't use SET_NETDEV_DEV for VAP.

I prefer to do nothing for now. The responsibility for fixing broken code should be primarily on the shoulders of those making the change. If code changes are needed, drivers/net/wireless/hostap/hostap_main.c has similar code, so we can copy the change from that file.

Thanks proski. I agree, lets wait until those changes actually happen, and do not waste effort pre-empting something that may or may not change.

Reassigning the ticket for version 0.9.3 then.

Compilation of r1846 against 2.6.18.5 worked without issues, so I expect that the described problem has been addressed in the kernel. Closing this ticket as fixed.