Re: [RFC][PATCH 8/9] 3c59x driver conversion
From: Jeff Garzik
Date: Wed Aug 09 2006 - 03:18:10 EST
Peter Zijlstra wrote:
On Wed, 2006-08-09 at 02:30 -0400, Jeff Garzik wrote:
David Miller wrote:
From: Daniel Phillips <phillips@xxxxxxxxxx>Pretty much. It is completely non-sensical to add NETIF_F_MEMALLOC,
when it should be blindingly obvious that every net driver will be
allocating memory, and every net driver could potentially be used with
NBD and similar situations.
Date: Tue, 08 Aug 2006 22:51:20 -0700
Elaborate please. Do you think that all drivers should be updated toI think he's saying that he doesn't think your code is yet a
fix the broken blockdev semantics, making NETIF_F_MEMALLOC redundant?
If so, I trust you will help audit for it?
reasonable way to solve the problem, and therefore doesn't belong
Sure, but until every single driver is converted I'd like to warn people
about the fact that their setups is not up to expectations. Iff all
drivers are converted I'll be the forst to submit a patch that removes
the feature flag.
A temporary-for-years flag is not a good approach. The flag is not
_needed_ for technical reasons, but for supposed user expectation reasons.
Rather, just go ahead and convert drivers to netdev_alloc_skb() where
people care. If someone suddenly gets a burr up their ass about the
sunlance or epic100 driver deadlocking on NBD, then they can convert it
or complain loudly themselves.
Overall, a good solution needs to be uniform across all net drivers.
NETIF_F_MEMALLOC is just _encouraging_ people to be slackers and delay
converting other drivers, creating two classes of drivers, the "haves"
and the "have nots".
Just make a big netdev_alloc_skb() patch that converts most users.
netdev_alloc_skb() is a good thing to use, because it builds an
association with struct net_device and the allocation.
P.S. Since netdev_alloc_skb() calls skb_reserve(), you need to take
that into account. That's a bug in current patches.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/