[Click] On patchless linux

[Eddie Kohler]

Thanks much!  This is a great idea; I've adopted it.  I changed the 
patch a bit so as to introduce the check only inside a header's 
#ifndef...#endif protection, when it has such protection.

Eddie


On 10/26/10 1:28 AM, Harald Schioeberg wrote:
> On Sun, 2010-10-24 at 09:45 -0700, Eddie Kohler wrote:
>> Hi Harald,
>>
>> Great to hear about other people using patchless!
>>
>> Re: hweight32: That is definitely a missing CLICK_CXX_PROTECT.  The way
>> to find it is to use nm on the individual object files to find where
>> it's used.  Something like
>>
>> for i in *.o; do if nm $i | grep -l hweight32>/dev/null 2>&1; then echo
>> $i; fi; done
>
> Hi Eddie,
> this was my first idea, too, but it yielded every single .o file....
>
> I traced down the bug by prepanding that to every linux header
> (thanks for fixincludes.pl ;-)
>
> #ifdef __cplusplus
> # ifndef CLICK_CXX_PROTECTED
> #  error "This file can only be included in CLICK_CXX_PROTECT stancas"
> # endif
> #endif
>
> compiles and loads for me now, patches attached
>
> (0002 is ommited for mailinglist friendliness, its just the huge diff
> autoconf will generate on the configure...)
>
>> More soon.
>>
>> Eddie
>>
>>
>> On 10/24/10 8:21 AM, Harald Schioeberg wrote:
>>> Hi,
>>>
>>> i'm currently trying to catch up with the patchless stuff, see below for
>>> my current status.
>>>
>>> I tried against the weird ubuntu-maverick kernel, but then
>>> I stepped back a bit to vanilla 2.6.27.54 on i386 for the moment.
>>> This gives me a click build, but with:
>>>
>>> WARNING:
>>> "_Z9hweight32j" [/data/harald/patchless/click/linuxmodule/click.ko]
>>> undefined!
>>> and of course a failure to load the "click" module, the proclikefs
>>> loads.
>>>
>>> Apparently hweigth32 is not CXX_PROTECTed, any ideas why this might
>>> happen?
>>> Its in click-linuxmodule/include0/asm-generic/bitops/hweight.h
>>> which should only be included via<linux/bitops.h>, but I have not found
>>> any unprotected "#include<linux/bitops.h>" or related stuff anywhere.
>>>
>>> Here I am starting from eddie/96471bf1 + from Joonwoo.
>>>
>>> [joonwoo 01/12]
>>> This fixes a configury issue, but the real compile will use [joonwoo
>>> 9/12], which is in mainline by now as 340c5ebe
>>> IMHO this needs some means to emulate
>>> LINUX_VERSION_CODE<   KERNEL_VERSION(2, 6, 33)
>>> in the configure to make it "nice"
>>>
>>> [joonwoo 02/12]
>>> I didn't need that one until now...
>>>
>>> [joonwoo 03/12]
>>> Same here
>>>
>>> [joonwoo 04/12]
>>> Used joonwoo's patch, discussion is ongoing between eddie and joonwoo
>>>
>>> [joonwoo 05/12] [joonwoo 06/12] are in mainline
>>>
>>> [joonwoo 07/12]
>>> used the patch from joowoon,
>>> eddie already confirmed the patch, but it's not in mainline yet
>>>
>>> [joonwoo 08/12]
>>> eddie checked in A Different Version
>>>
>>> [joonwoo 09/12]
>>> it's upstream, related to 01/12
>>>
>>> [joonwoo 10/12 and 11/12]
>>> they are upstream
>>>
>>> [joonwoo 12/12]
>>> A Different Version is upstream as a5f200d
>>>
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>