Skip to contentSkip to conversation

remove CONFIG_HAVE_ARCH_DEV_ALLOC_SKB

PATCH Applied Christoph Hellwig 3 participants 4 messages Jul 7, 2006 – Jul 26, 2006

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/2 remove CONFIG_HAVE_ARCH_DEV_ALLOC_SKB

skbuff.h has an #ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB to allow architectures to reimplement __dev_alloc_skb. It's not set on any architecture and now that we have an architecture-overrideable NET_SKB_PAD there is not point at all to have one either.

include/linux/skbuff.h +0 -4
Index: linux-2.6/include/linux/skbuff.h
===================================================================
@@ -1066,7 +1066,6 @@
 		kfree_skb(skb);
 }
 
-#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
 /**
  *	__dev_alloc_skb - allocate an skbuff for sending
  *	@length: length to allocate
@@ -1087,9 +1086,6 @@
 		skb_reserve(skb, NET_SKB_PAD);
 	return skb;
 }
-#else
-extern struct sk_buff *__dev_alloc_skb(unsigned int length, int gfp_mask);
-#endif
 
 /**
  *	dev_alloc_skb - allocate an skbuff for sending
maintainer Applied
#1 lore raw

From: Christoph Hellwig <[email protected]>
Date: Fri, 7 Jul 2006 11:10:08 +0200

Quoted 7 lines

skbuff.h has an #ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB to allow architectures to reimplement __dev_alloc_skb. It's not set on any architecture and now that we have an architecture-overrideable NET_SKB_PAD there is not point at all to have one either.

Applied, thanks Christoph.

#2 lore raw
Quoted 4 lines

skbuff.h has an #ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB to allow architectures to reimplement __dev_alloc_skb. It's not set on any architecture and now that we have an architecture-overrideable NET_SKB_PAD there is not point at all to have one either.

I missed this when hch first posted it, sorry.

But my impression was that the intent of the config option was to let Xen hook __dev_alloc_skb() to allocate special receive skbs to handle their page-flipping virtual network device. Which goes beyond NET_SKB_PAD.

So the real question is about Xen hooks I guess -- and given where the rest of Xen is, it probably does make sense to go ahead and strip this out.

- R.

#3 lore raw
Quoted 7 lines · Roland Dreier
Quoted 4 lines

skbuff.h has an #ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB to allow architectures to reimplement __dev_alloc_skb. It's not set on any architecture and now that we have an architecture-overrideable NET_SKB_PAD there is not point at all to have one either.

I missed this when hch first posted it, sorry.

Quoted 8 lines

But my impression was that the intent of the config option was to let Xen hook __dev_alloc_skb() to allocate special receive skbs to handle their page-flipping virtual network device. Which goes beyond NET_SKB_PAD.

So the real question is about Xen hooks I guess -- and given where the rest of Xen is, it probably does make sense to go ahead and strip this out.

If xen wants to use something else then dev_alloc_skb in their virtual network driver that's totall fine. No need to override the definiton of dev_alloc_skb for that, though. They can add their own xen_alloc_skb or opencode the operation they want for it.

Note that overriding dev_alloc_skb is not just utterly pointless but would even be harmfull in the case they'd finally add pci support for non-dom0 domains and used normaly NIC drivers in there.