remove CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
Subsystems (2)
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
@@ -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
From: Christoph Hellwig <[email protected]>
Date: Fri, 7 Jul 2006 11:10:08 +0200
Quoted 7 lines
skbuff.hhas an #ifndefCONFIG_HAVE_ARCH_DEV_ALLOC_SKBto allow architectures to reimplement__dev_alloc_skb. It's not set on any architecture and now that we have an architecture-overrideableNET_SKB_PADthere is not point at all to have one either.Signed-off-by Christoph Hellwig <[email protected]>
Applied, thanks Christoph.
Quoted 4 lines
skbuff.hhas an #ifndefCONFIG_HAVE_ARCH_DEV_ALLOC_SKBto allow architectures to reimplement__dev_alloc_skb. It's not set on any architecture and now that we have an architecture-overrideableNET_SKB_PADthere 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.
Quoted 7 lines · Roland Dreier
Quoted 4 lines
skbuff.hhas an #ifndefCONFIG_HAVE_ARCH_DEV_ALLOC_SKBto allow architectures to reimplement__dev_alloc_skb. It's not set on any architecture and now that we have an architecture-overrideableNET_SKB_PADthere 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 beyondNET_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.