All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: David Miller <davem@davemloft.net>, netdev <netdev@vger.kernel.org>
Subject: Re: compile breakage due to [SK_BUFF]: Convert skb->end to sk_buff_data_t
Date: Sun, 13 May 2007 20:27:35 -0300	[thread overview]
Message-ID: <46479EE7.1030100@redhat.com> (raw)
In-Reply-To: <20070513182941.GC4343@rhun.haifa.ibm.com>

Muli Ben-Yehuda wrote:
> On Fri, Apr 27, 2007 at 05:03:44PM +0000, Linux Kernel Mailing List wrote:
>
>   
>> Gitweb:     http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4305b541357ddbd205aa145dc378926b7cb12283
>> Commit:     4305b541357ddbd205aa145dc378926b7cb12283
>> Parent:     27a884dc3cb63b93c2b3b643f5b31eed5f8a4d26
>> Author:     Arnaldo Carvalho de Melo <acme@redhat.com>
>> AuthorDate: Thu Apr 19 20:43:29 2007 -0700
>> Committer:  David S. Miller <davem@sunset.davemloft.net>
>> CommitDate: Wed Apr 25 22:26:29 2007 -0700
>>
>>     [SK_BUFF]: Convert skb->end to sk_buff_data_t
>>     
>>     Now to convert the last one, skb->data, that will allow many simplifications
>>     and removal of some of the offset helpers.
>>     
>>     Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>>     Signed-off-by: David S. Miller <davem@davemloft.net>
>>     
>
> This patch and the previous one breaks the compilation on one of my
> machines. Specifically, this bit:
>
>   
>> @@ -632,12 +644,13 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
>>  	/* Copy only real data... and, alas, header. This should be
>>  	 * optimized for the cases when header is void. */
>>  	memcpy(data + nhead, skb->head,
>> -		skb->tail
>> -#ifndef NET_SKBUFF_DATA_USES_OFFSET
>> -		- skb->head
>> +#ifdef NET_SKBUFF_DATA_USES_OFFSET
>> +		skb->tail);
>> +#else
>> +		skb->tail - skb->head);
>>  #endif
>> -		);
>> -	memcpy(data + size, skb->end, sizeof(struct skb_shared_info));
>> +	memcpy(data + size, skb_end_pointer(skb),
>> +	       sizeof(struct skb_shared_info));
>>  
>>  	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
>>  		get_page(skb_shinfo(skb)->frags[i].page);
>>     
>
> Causes this compile error:
>
> /home/muli/kernel/trident/trident.git/net/core/skbuff.c:648:1: directives may not be used inside a macro argument
> /home/muli/kernel/trident/trident.git/net/core/skbuff.c:647:39: unterminated argument list invoking macro "memcpy"
> /home/muli/kernel/trident/trident.git/net/core/skbuff.c: In function `pskb_expand_head':
> /home/muli/kernel/trident/trident.git/net/core/skbuff.c:651: `memcpy' undeclared (first use in this function)
> /home/muli/kernel/trident/trident.git/net/core/skbuff.c:651: (Each undeclared identifier is reported only once
> /home/muli/kernel/trident/trident.git/net/core/skbuff.c:651: for each function it appears in.)
> /home/muli/kernel/trident/trident.git/net/core/skbuff.c:651: syntax error before "skb"
>
> muli@rhun:~/kernel/trident/trident.git$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-53)
>
> It happens because memcpy ends up being a macro, and this gcc dislikes
> having a preprocessor directive inside a macro argument. I don't know
> if if it's valid in general, but Documentation/Changes does say we
> still support gcc 3.2...
>   

Well, the fix is easy, can you provide a patch?

- Arnaldo

  reply	other threads:[~2007-05-13 23:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200704271703.l3RH3i2F021726@hera.kernel.org>
2007-05-13 18:29 ` compile breakage due to [SK_BUFF]: Convert skb->end to sk_buff_data_t Muli Ben-Yehuda
2007-05-13 23:27   ` Arnaldo Carvalho de Melo [this message]
2007-05-14  0:27     ` Randy Dunlap
2007-05-14  5:42     ` Muli Ben-Yehuda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46479EE7.1030100@redhat.com \
    --to=acme@redhat.com \
    --cc=davem@davemloft.net \
    --cc=muli@il.ibm.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.