--- Begin Message ---
- From: Joonwoo Park <joonwpark81 at gmail dot com>
- To: Philip Prindeville <philipp_subx at redfish-solutions dot com>
- Cc: click at amsterdam dot lcs dot mit dot edu
- Date: Tue, 4 Jan 2011 12:25:33 -0800
- Subject: Re: [Click] Minimizing patch size
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i+F2OnRqeSXy/3iiThqRx8jAm/A+sQFIhIXEBJeyTRE=; b=WMvU0gW5fd+lpR+LmuOaAstwpdDGAqYsAf1ECuluNOmVJDlf13BHDUitRc8RDxQwDe ZDtJJuAzUKcVRSTraG3K2LMLmqAor7hj0MkByUK2JiaBDz68HDbm0y2HDTgPsbhDPtZ7 23Ogi6duK6G5voxZAQBehETKPeGGEo/6B5mGg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jfiMKEfSIRxoaknGtjubIc3/XkpbmNEpTGbDFw6WJBvcWMIcazuzBINCVr6vxdV5Sh 6ATras05+9mmKidw2hFYMSZbyzRHx+GtbtSPJ6gRwPc7c7RZj12/OJZc4UT3Ya6scgKF SYlRmewyISHqFtsRvhtQCUhlI9Ypmb5EZqEb4=
- References: <4D22D241.20903@redfish-solutions.com><AANLkTi=7+mi5TBnEQcA0GjreG_rYOHYO9=D3mF+RrbLn@mail.gmail.com><4D237EC0.3070505@redfish-solutions.com>
Hi Philip,
---
joonwpark@ $ cat -n keyword.cpp
1 #include <iostream>
2
3 extern "C"
4 {
5 struct keyword {
6 int new;
7 };
8 }
9
10 int main()
11 {
12 return 0;
13 }
joonwpark@ $ g++ keyword.cpp
keyword.cpp:6: error: expected unqualified-id before ‘new’
---
Joonwoo
On Tue, Jan 4, 2011 at 12:10 PM, Philip Prindeville
<philipp_subx@redfish-solutions.com> wrote:
> Inline...
>
>
> On 1/4/11 11:18 AM, Joonwoo Park wrote:
>>
>> Hi Philip,
>>
>> (2) The reason of patching "::" to ": :" is because "::" is namespace
>> keyword of c++ as you know.
>> It must be true that we can leave "::" in .c file as we builds .c with
>> c compiler not c++, however if "::" is in .h, since that .h will
>> possibly be included from .cpp file click linuxmodule, we need to
>> patch "::" to ": :" by all means.
>
> I still don't get this. ?Even in a .cpp file, you can have
>
> c++ stuff
> ...
> extern "C" {
> #include "c-header-with-double-colon-asms.h"
> }
> ...
>
> and the compiler should be fine with that.
>
> If not, then the compiler is broken.
>
>
>> Therefore I made a simple script to change every "::" to ": :" and
>> generated patch when I made patch for 2.6.24.7, I think you can revert
>> "::" changes in .c files if you'd like to do.
>> (3) compat shim would seem to me for finding out correct symbol table,
>> but since click uses c++ compiler .h has be modified to make c++
>> compiler happy, ?I think we still need to provide c++ compile-able .h
>> files. ?ie) structure member initializer, c++ keyword and etc... which
>> cannot be solved by 'extern "C"' keyword.
>
> Have you tried? ?What was the result?
>
> C is supposed to be a subset of the C++ language when in the "C" namespace,
> which is activated by extern "C".
>
>> (1) At any rate, for recent version of linux, I believe right
>> direction is improving patchless to support newer version without
>> patching linux.
>>
>> Joonwoo
>>
>> On Mon, Jan 3, 2011 at 11:54 PM, Philip Prindeville
>> <philipp_subx@redfish-solutions.com> ?wrote:
>>>
>>> I was looking at the click kernel patches and noticed two things.
>>>
>>> (1) none of the kernels seem to be particularly recent.
>>> (2) a lot of the patches seem to be something other than added
>>> functionality.
>>>
>>> Looking, for instance, at:
>>>
>>> diff --git a/arch/arm/mach-iop13xx/irq.c b/arch/arm/mach-iop13xx/irq.c
>>> index 69f07b2..e217167 100644
>>> --- a/arch/arm/mach-iop13xx/irq.c
>>> +++ b/arch/arm/mach-iop13xx/irq.c
>>> @@ -38,7 +38,7 @@ static u32 read_intctl_0(void)
>>> ?}
>>> ?static void write_intctl_0(u32 val)
>>> ?{
>>> - ? ? ? asm volatile("mcr p6, 0, %0, c0, c4, 0"::"r" (val));
>>> + ? ? ? asm volatile("mcr p6, 0, %0, c0, c4, 0": :"r" (val));
>>> ?}
>>>
>>> ...
>>>
>>>
>>> I'm wondering why this is required? First, why would the C++ compiler try
>>> to compile a .c file, and second, why would it not be able to parse an asm()
>>> directive correctly?
>>>
>>> Looking over the patches, the "essential" ones are less than a thousand
>>> lines.
>>>
>>> (3) I work a bit with the compat-wireless group, and they've managed to
>>> come up with a loadable module that provides "shim" functionality that
>>> allows the most recent wireless (wifi) drivers to load and run against older
>>> kernels. ?I can use a 2.6.37 driver with a 2.6.27 kernel (even with the skb
>>> changes that occurred in the interim).
>>>
>>> It should be possible to do something similar for click.
>>>
>>> The only substantive change is adding new member fields to netdevice.h.
>>>
>>> What about using a Makefile adaptation like:
>>>
>>> %.o: %.c:
>>> ? ? ? ?(echo '#ifdef __cplusplus' ; \
>>> ? ? ? ? echo 'extern "C" {' ; \
>>> ? ? ? ? echo '#endif' ; \
>>> ? ? ? ? echo '# 0 "$<"' ; \
>>> ? ? ? ? cat $< ? ?; \
>>> ? ? ? ? echo '#ifdef __cplusplus' ; \
>>> ? ? ? ? echo '}' ; \
>>> ? ? ? ? echo '#endif' ) | $(CC) $(CFLAGS) -c - -o $@
>>>
>>>
>>> to bracket the contents of C files with:
>>>
>>> #ifdef __cplusplus
>>> extern "C" {
>>> #endif
>>> ...
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>>
>>> and compile them that way?
>>>
>>> I'm not sure if the debugging symbols would still be valid, or if they'd
>>> point to the wrong source files, but there are ways to patch that up with
>>> objcopy.
>>>
>>> Comments?
>>>
>>> Thanks,
>>>
>>> -Philip
>>>
>>> _______________________________________________
>>> click mailing list
>>> click@amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>
>
>
--- End Message ---