* Re: 2.6.17: networking bug??
From: Matt Mackall @ 2006-06-13 23:22 UTC (permalink / raw)
To: Mark Lord; +Cc: David Miller, jheffner, torvalds, linux-kernel, netdev
In-Reply-To: <448F32E1.8080002@rtr.ca>
On Tue, Jun 13, 2006 at 05:49:21PM -0400, Mark Lord wrote:
>
>
> David Miller wrote:
> >..
> >First, you are getting window scaling by default with the older
> >kernel too. It's just a smaller window scale, using a shift
> >value of say 1 or 2.
> >
> >What these broken middle boxes do is ignore the window scale
> >entirely.
> >
> >So they don't apply a window scale to the advertised windows in each
> >packet. Therefore, they think a smaller amount of window space is
> >being advertised than really is. So they will silently drop packets
> >they think is outside of this bogus window they've calculated.
> >
> >Now, when the window scale is smaller, the connection can still limp
> >along, albeit slowly, making forward progress even in the face of such
> >broken devices because half or a quarter of the window is still
> >available. It will retransmit a lot, and the congestion window won't
> >grow at all.
> >
> >When the window scale is larger, this middle box bug makes it such
> >that not even one packet can fit into the miscalculated window and
> >things wedge. The box thinks that your window is "94" instead of
> >"94 << WINDOW_SCALE".
> ..
>
> Unilaterally following the standard is all well and good
> for those who know how to get around it when a site becomes
> inaccessible, but not for Joe User.
We had very similar issues with ECN. But unlike ECN, window scaling is
not something we can just shrug our shoulders and say "oh well" about.
We will have to deal with it eventually. It might as well be sooner.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Ben Greear @ 2006-06-13 23:42 UTC (permalink / raw)
To: Chase Venters
Cc: Brian F. G. Bidulock, Daniel Phillips, Stephen Hemminger,
Sridhar Samudrala, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0606131655580.4856@turbotaz.ourhouse>
Chase Venters wrote:
> At least some of us feel like stable module APIs should be explicitly
> discouraged, because we don't want to offer comfort for code that
> refuses to live in the tree (since getting said code into the tree is
> often a goal).
Some of us write modules for specific features that are not wanted in
the mainline kernel, even though they are pure GPL. Our life is hard
enough with out people setting out to deliberately make things more
difficult!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-13 23:55 UTC (permalink / raw)
To: Valerie Henson; +Cc: Jeff Garzik, Andrew Morton, netdev
In-Reply-To: <20060608170120.GI8246@colo.lackof.org>
On Thu, Jun 08, 2006 at 11:01:20AM -0600, Grant Grundler wrote:
> Here is a new patch that moves free_irq() into tulip_down().
> The resulting code is structured the same as cp_close().
Val,
Two details are wrong in version 2 and are fixed in v3 (appended below):
o we don't need synchronize_irq() before calling free_irq().
(It should be removed from cp_close() too)
Thanks to willy for pointing me at kernel/irq/manage.c.
o tulip_stop_rxtx() has to be called _after_ free_irq().
ie. v2 patch didn't fix the original race condition
and when under test, dies about as fast as the original code.
Tested on rx4640 (HP IA64) for several hours.
Please apply.
thanks,
grant
Change Log:
IRQs are racing with tulip_down(). DMA can be restarted _after_
we call tulip_stop_rxtx() and the DMA buffers are unmapped.
The result is an MCA (hard crash on ia64) because of an
IO TLB miss.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -18,11 +18,11 @@
#define DRV_NAME "tulip"
#ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION "1.1.13-NAPI" /* Keep at least for test */
+#define DRV_VERSION "1.1.14-NAPI" /* Keep at least for test */
#else
-#define DRV_VERSION "1.1.13"
+#define DRV_VERSION "1.1.14"
#endif
-#define DRV_RELDATE "December 15, 2004"
+#define DRV_RELDATE "May 6, 2006"
#include <linux/module.h>
@@ -741,21 +741,20 @@ static void tulip_down (struct net_devic
/* Disable interrupts by clearing the interrupt mask. */
iowrite32 (0x00000000, ioaddr + CSR7);
+ ioread32 (ioaddr + CSR7); /* flush posted write */
- /* Stop the Tx and Rx processes. */
- tulip_stop_rxtx(tp);
+ spin_unlock_irqrestore (&tp->lock, flags);
- /* prepare receive buffers */
- tulip_refill_rx(dev);
+ free_irq (dev->irq, dev); /* no more races after this */
+ tulip_stop_rxtx(tp); /* Stop DMA */
- /* release any unconsumed transmit buffers */
- tulip_clean_tx_ring(tp);
+ /* Put driver back into the state we start with */
+ tulip_refill_rx(dev); /* prepare RX buffers */
+ tulip_clean_tx_ring(tp); /* clean up unsent TX buffers */
if (ioread32 (ioaddr + CSR6) != 0xffffffff)
tp->stats.rx_missed_errors += ioread32 (ioaddr + CSR8) & 0xffff;
- spin_unlock_irqrestore (&tp->lock, flags);
-
init_timer(&tp->timer);
tp->timer.data = (unsigned long)dev;
tp->timer.function = tulip_tbl[tp->chip_id].media_timer;
@@ -774,7 +773,6 @@ static int tulip_close (struct net_devic
printk (KERN_DEBUG "%s: Shutting down ethercard, status was %2.2x.\n",
dev->name, ioread32 (ioaddr + CSR5));
- free_irq (dev->irq, dev);
/* Free all the skbuffs in the Rx queue. */
for (i = 0; i < RX_RING_SIZE; i++) {
@@ -1752,7 +1752,6 @@ static int tulip_suspend (struct pci_dev
tulip_down(dev);
netif_device_detach(dev);
- free_irq(dev->irq, dev);
pci_save_state(pdev);
pci_disable_device(pdev);
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Chase Venters @ 2006-06-13 23:59 UTC (permalink / raw)
To: bidulock
Cc: Daniel Phillips, Stephen Hemminger, Sridhar Samudrala, netdev,
linux-kernel
In-Reply-To: <20060613164714.B7232@openss7.org>
On Tuesday 13 June 2006 17:46, Brian F. G. Bidulock wrote:
> Daniel,
>
> On Tue, 13 Jun 2006, Daniel Phillips wrote:
> > You probably meant "non-GPL-compatible non-proprietary". If so, then by
> > definition there are none.
>
> Well, being GPL compatible is not a requirement for an open source license.
>
> IANAL, but last I checked, pure-BSD is not compatible with GPL (it actually
> has to be dual-licensed BSD/GPL).
It depends on what you mean by "pure-BSD". If you're talking about the
4-clause license with the advertising clause, then you are correct. Otherwise
(IANAL) but my understanding is that BSD code can even be relicensed GPL by a
third party contribution (though it is perhaps kind to ask for relicensing
permission anyway).
From your other message:
> To some it is a serious failing of Linux (particularly those involved in
> porting kernel modules from branded UNIX or embedded RTOS). To those
> whatever stability that can be offered is a boon. To those, even worse is
> the lack of an ABI (even for a single kernel version).
Then would offering a 'stable API in disguise' not be a disaster and an
irritation to these people? If the kernel doesn't specify that an in-kernel
interface is stable, then there is no reason to expect it to be. It might not
change, but there won't be too much sympathy for out-of-tree users if it
does. The kernel comes with big warnings about the lack of a stable API for a
reason.
> Another thing to consider is that the first step for many organizations in
> opening a driver under GPL is to release a proprietary module that at least
> first works.
If the driver is an old-tech Linux port, then it seems there isn't too much
stopping them from doing this today (aside from the fact that some people
think proprietary modules are murky anyway). In this case, we don't want a
stable API/ABI, because then we leave them with little incentive to open the
code.
And if the driver is new code, they're better off doing an open driver from
the start (especially since writing a driver _for_ Linux, as opposed to
porting one, might make it count as 'derived' and hence unlawful unless
released GPL).
> Sorry for the rant.
We're not as perfect as I wish we were. But the lack of stable API (dead
horse) is something that is fairly well established and understood. I think
most people feel that the cost-benefit analysis, for Linux anyway, strongly
favors no stable API.
Thanks,
Chase
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Chase Venters @ 2006-06-14 0:05 UTC (permalink / raw)
To: Ben Greear
Cc: Brian F. G. Bidulock, Daniel Phillips, Stephen Hemminger,
Sridhar Samudrala, netdev, linux-kernel
In-Reply-To: <448F4D6F.9070601@candelatech.com>
On Tuesday 13 June 2006 18:42, Ben Greear wrote:
> Chase Venters wrote:
> > At least some of us feel like stable module APIs should be explicitly
> > discouraged, because we don't want to offer comfort for code that
> > refuses to live in the tree (since getting said code into the tree is
> > often a goal).
>
> Some of us write modules for specific features that are not wanted in
> the mainline kernel, even though they are pure GPL. Our life is hard
> enough with out people setting out to deliberately make things more
> difficult!
Fair enough, but if you are doing out of tree, pure GPL modules,
EXPORT_SYMBOL_GPL() isn't a bad thing, is it?
Don't mistake me for actually having a big opinion specifically about this
socket API's usage of EXPORT_SYMBOL()... just raising some points that I
think apply to these decisions in general. I don't really see a compelling
reason for EXPORT_SYMBOL() over EXPORT_SYMBOL_GPL() on the socket APIs
though... I'm trying to imagine what kind of legitimate non-GPL modules might
use them.
> Ben
Thanks,
Chase
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Valerie Henson @ 2006-06-14 0:06 UTC (permalink / raw)
To: Grant Grundler; +Cc: Jeff Garzik, Andrew Morton, netdev
In-Reply-To: <20060613235531.GA4191@colo.lackof.org>
On Tue, Jun 13, 2006 at 05:55:31PM -0600, Grant Grundler wrote:
> On Thu, Jun 08, 2006 at 11:01:20AM -0600, Grant Grundler wrote:
> > Here is a new patch that moves free_irq() into tulip_down().
> > The resulting code is structured the same as cp_close().
>
> Val,
> Two details are wrong in version 2 and are fixed in v3 (appended below):
>
> o we don't need synchronize_irq() before calling free_irq().
> (It should be removed from cp_close() too)
> Thanks to willy for pointing me at kernel/irq/manage.c.
>
> o tulip_stop_rxtx() has to be called _after_ free_irq().
> ie. v2 patch didn't fix the original race condition
> and when under test, dies about as fast as the original code.
>
> Tested on rx4640 (HP IA64) for several hours.
> Please apply.
Thanks, I'll take a look next week (after the workshop and moving).
-VAL
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-14 0:18 UTC (permalink / raw)
To: Chase Venters
Cc: Ben Greear, Daniel Phillips, Stephen Hemminger, Sridhar Samudrala,
netdev, linux-kernel
In-Reply-To: <200606131906.16683.chase.venters@clientec.com>
Chase,
On Tue, 13 Jun 2006, Chase Venters wrote:
> I'm trying to imagine what kind of legitimate non-GPL modules might
> use them.
Example: in-kernel RTP implementation derived from AT&T rtp-lib
implementation (non-GPL compatible license) utilizing this kernel
interface for UDP socket access.
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Ben Greear @ 2006-06-14 0:19 UTC (permalink / raw)
To: Chase Venters
Cc: Brian F. G. Bidulock, Daniel Phillips, Stephen Hemminger,
Sridhar Samudrala, netdev, linux-kernel
In-Reply-To: <200606131906.16683.chase.venters@clientec.com>
Chase Venters wrote:
> On Tuesday 13 June 2006 18:42, Ben Greear wrote:
>
>>Chase Venters wrote:
>>
>>>At least some of us feel like stable module APIs should be explicitly
>>>discouraged, because we don't want to offer comfort for code that
>>>refuses to live in the tree (since getting said code into the tree is
>>>often a goal).
>>
>>Some of us write modules for specific features that are not wanted in
>>the mainline kernel, even though they are pure GPL. Our life is hard
>>enough with out people setting out to deliberately make things more
>>difficult!
>
>
> Fair enough, but if you are doing out of tree, pure GPL modules,
> EXPORT_SYMBOL_GPL() isn't a bad thing, is it?
>
> Don't mistake me for actually having a big opinion specifically about this
> socket API's usage of EXPORT_SYMBOL()... just raising some points that I
> think apply to these decisions in general. I don't really see a compelling
> reason for EXPORT_SYMBOL() over EXPORT_SYMBOL_GPL() on the socket APIs
> though... I'm trying to imagine what kind of legitimate non-GPL modules might
> use them.
I got to the flame war late and only saw your comment that stable API should
be discouraged. That kind of thinking pisses me off because it assumes all
modules out of the tree are that way because the authors want them out of the
tree. I also understand that sometimes API needs to change, but please don't
encourage change just to punish other authors, be they proprietary or otherwise.
As for what type of EXPORT macro to use I surely don't have anything to
say that hasn't been said multiple times before.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Chase Venters @ 2006-06-14 0:29 UTC (permalink / raw)
To: bidulock
Cc: Ben Greear, Daniel Phillips, Stephen Hemminger, Sridhar Samudrala,
netdev, linux-kernel
In-Reply-To: <20060613181801.A8460@openss7.org>
On Tuesday 13 June 2006 19:17, Brian F. G. Bidulock wrote:
> Chase,
>
> On Tue, 13 Jun 2006, Chase Venters wrote:
> > I'm trying to imagine what kind of legitimate non-GPL modules might
> > use them.
>
> Example: in-kernel RTP implementation derived from AT&T rtp-lib
> implementation (non-GPL compatible license) utilizing this kernel
> interface for UDP socket access.
I don't mean to be obtuse, but the "Non-exclusive Non-commercial Limited-use
Source" license seems to make something like that have limited usefulness in
general. That is -- unless one were to obtain a commercial license from AT&T,
but then that starts falling into the domain of what is likely prohibited by
the GPL (some sort of proprietary work actually _derived_ off the kernel
rather than just supporting it in some way).
But I did ask for examples...
Thanks,
Chase
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-14 0:31 UTC (permalink / raw)
To: Chase Venters
Cc: Daniel Phillips, Stephen Hemminger, Sridhar Samudrala, netdev,
linux-kernel
In-Reply-To: <200606131859.43695.chase.venters@clientec.com>
Chase,
On Tue, 13 Jun 2006, Chase Venters wrote:
>
> It depends on what you mean by "pure-BSD". If you're talking about the
> 4-clause license with the advertising clause, then you are correct. Otherwise
> (IANAL) but my understanding is that BSD code can even be relicensed GPL by a
> third party contribution (though it is perhaps kind to ask for relicensing
> permission anyway).
Yes, and the long list of open source licenses listed on the FSF website
as incompatible with the GPL.
> Then would offering a 'stable API in disguise' not be a disaster and an
> irritation to these people? If the kernel doesn't specify that an in-kernel
> interface is stable, then there is no reason to expect it to be. It might not
> change, but there won't be too much sympathy for out-of-tree users if it
> does. The kernel comes with big warnings about the lack of a stable API for a
> reason.
In fact most core kernel facilities (spin lock, memory caches, character and
block device interface, even core file system) have had a very stable API
(way back to early 2.4 kernels). An in fact most of them are derived from
some variant or precursor to UNIX. For example, memory caches are a Sun
Solaris concept.
It is the lack of an ABI that is most frustrating to these users.
>
> > Another thing to consider is that the first step for many organizations in
> > opening a driver under GPL is to release a proprietary module that at least
> > first works.
>
> If the driver is an old-tech Linux port, then it seems there isn't too much
> stopping them from doing this today (aside from the fact that some people
> think proprietary modules are murky anyway). In this case, we don't want a
> stable API/ABI, because then we leave them with little incentive to open the
> code.
"old-tech"? No, these are high-tech drivers supported by commercial RTOS,
from which Linux stands to benefit. And, by not allowing these organizations
to take the first step (generate a workable Linux driver) such a policy
provides them little incentive to ever move the driver to Linux, and cuts
them off from opening it.
I don't think that it is fair to say that an unstable API/ABI, in of itself,
provides an incentive to open an existing proprietary driver.
> We're not as perfect as I wish we were. But the lack of stable API (dead
> horse) is something that is fairly well established and understood. I think
> most people feel that the cost-benefit analysis, for Linux anyway, strongly
> favors no stable API.
Well, the lack of a stable ABI is well known. The API is largely stable (but
not sacrosanctly so) for the major reason that changing it within a large
code base is difficult and error prone at best.
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Jeff Garzik @ 2006-06-14 0:33 UTC (permalink / raw)
To: Grant Grundler; +Cc: Valerie Henson, Andrew Morton, netdev
In-Reply-To: <20060613235531.GA4191@colo.lackof.org>
Grant Grundler wrote:
> o tulip_stop_rxtx() has to be called _after_ free_irq().
> ie. v2 patch didn't fix the original race condition
> and when under test, dies about as fast as the original code.
You made the race window smaller, but it's still there. The chip's DMA
engines should be stopped before you unregister the interrupt handler.
Jeff
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-14 0:36 UTC (permalink / raw)
To: Chase Venters
Cc: Ben Greear, Daniel Phillips, Stephen Hemminger, Sridhar Samudrala,
netdev, linux-kernel
In-Reply-To: <200606131929.41985.chase.venters@clientec.com>
Chase,
On Tue, 13 Jun 2006, Chase Venters wrote:
>
> But I did ask for examples...
Perhaps the license isn't a good example, but there are other RTP
stacks that are non-GPL compatible. Also, if it includes SSL code
for SRTP, SSL license happens to be non-GPL compatible.
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-14 0:38 UTC (permalink / raw)
To: Ben Greear
Cc: Chase Venters, Daniel Phillips, Stephen Hemminger,
Sridhar Samudrala, netdev, linux-kernel
In-Reply-To: <448F561D.5080007@candelatech.com>
Ben,
On Tue, 13 Jun 2006, Ben Greear wrote:
>
> I got to the flame war late
...
I think we're trying to have an honest open discussion here. I certainly
don't mean to flame anyone and apologize if my remarks have been taken so.
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Chase Venters @ 2006-06-14 0:53 UTC (permalink / raw)
To: bidulock
Cc: Daniel Phillips, Stephen Hemminger, Sridhar Samudrala, netdev,
linux-kernel
In-Reply-To: <20060613183112.B8460@openss7.org>
On Tuesday 13 June 2006 19:30, Brian F. G. Bidulock wrote:
> Yes, and the long list of open source licenses listed on the FSF website
> as incompatible with the GPL.
Conceded, I suppose. The usage of EXPORT_SYMBOL() though tends to be for the
reason of enabling drivers to offer functionality to the kernel -- not for
people who want to turn the kernel into applications. (Consider for example
how netfilter is exposed as GPL. You can build applications [routers] out of
it, but in that case you're doing a work derived off of Linux, and you should
be abiding by its GPL licensing terms)
> > Then would offering a 'stable API in disguise' not be a disaster and an
> > irritation to these people? If the kernel doesn't specify that an
> > in-kernel interface is stable, then there is no reason to expect it to
> > be. It might not change, but there won't be too much sympathy for
> > out-of-tree users if it does. The kernel comes with big warnings about
> > the lack of a stable API for a reason.
>
> In fact most core kernel facilities (spin lock, memory caches, character
> and block device interface, even core file system) have had a very stable
> API (way back to early 2.4 kernels). An in fact most of them are derived
> from some variant or precursor to UNIX. For example, memory caches are a
> Sun Solaris concept.
I'm not advocating changing the API for no reason / just to piss off out of
tree developers. I'm just trying to make clear that in these cases, 'stable'
is just an observation -- not something you can count on.
> It is the lack of an ABI that is most frustrating to these users.
And the presence of an ABI would be _very_ frustrating to core developers. Not
only would these people suffer, everyone would -- developer time would be
wasted dealing with cruft, and forward progress would be slowed.
> > > Another thing to consider is that the first step for many organizations
> > > in opening a driver under GPL is to release a proprietary module that
> > > at least first works.
> >
> > If the driver is an old-tech Linux port, then it seems there isn't too
> > much stopping them from doing this today (aside from the fact that some
> > people think proprietary modules are murky anyway). In this case, we
> > don't want a stable API/ABI, because then we leave them with little
> > incentive to open the code.
>
> "old-tech"? No, these are high-tech drivers supported by commercial RTOS,
> from which Linux stands to benefit. And, by not allowing these
> organizations to take the first step (generate a workable Linux driver)
> such a policy provides them little incentive to ever move the driver to
> Linux, and cuts them off from opening it.
Perhaps another term may have been more appropriate. What I mean by 'old tech'
is more 'existing code' -- ie, something you would port.
And these organizations _are_ afforded the opportunity to take the first step
-- that's why interfaces critical to drivers are currently EXPORT_SYMBOL().
> I don't think that it is fair to say that an unstable API/ABI, in of
> itself, provides an incentive to open an existing proprietary driver.
Sure it does, depending on your perspective and what you're willing to
consider. The lack of a stable API/ABI means that if you don't want to have
to do work tracking the kernel, you should push to have your drivers merged.
> > We're not as perfect as I wish we were. But the lack of stable API (dead
> > horse) is something that is fairly well established and understood. I
> > think most people feel that the cost-benefit analysis, for Linux anyway,
> > strongly favors no stable API.
>
> Well, the lack of a stable ABI is well known. The API is largely stable
> (but not sacrosanctly so) for the major reason that changing it within a
> large code base is difficult and error prone at best.
Perhaps, but calling it 'stable' in any sense other than idle observation is a
disaster, because the idea leads to pain and suffering when you do have a
major reason to change the API.
Thanks,
Chase
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: John Heffner @ 2006-06-14 1:25 UTC (permalink / raw)
To: Rick Jones; +Cc: David Miller, netdev
In-Reply-To: <448F3EF5.50701@hp.com>
Rick Jones wrote:
>> One final word about window sizes. If you have a connection whose
>> bandwidth-delay-product needs an N byte buffer to fill, you actually
>> have to have an "N * 2" sized buffer available in order for fast
>> retransmit to work.
>
> Is that as important in the presence of SACK?
With SACK you do need up to N * 2, but no more. With New Reno, you
potentially need ~ N * (number of losses) or it will time out... yuck.
SACK is a good thing. :)
-John
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-14 4:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Grant Grundler, Valerie Henson, Andrew Morton, netdev
In-Reply-To: <448F5952.1060201@pobox.com>
On Tue, Jun 13, 2006 at 08:33:22PM -0400, Jeff Garzik wrote:
> Grant Grundler wrote:
> >o tulip_stop_rxtx() has to be called _after_ free_irq().
> > ie. v2 patch didn't fix the original race condition
> > and when under test, dies about as fast as the original code.
>
> You made the race window smaller, but it's still there. The chip's DMA
> engines should be stopped before you unregister the interrupt handler.
Switching the order to be:
tulip_stop_rxtx(tp); /* Stop DMA */
free_irq (dev->irq, dev); /* no more races after this */
still leaves us open to IRQs being delivered _after_ we've stopped DMA.
That in turn allows the interrupt handler to re-enable DMA again.
Or are you worried about a masked, pending interrupt causing
problems when the driver is re-opened or resumed?
If firmware left the device in a that state at boot time wouldn't
the driver be required to handle it?
thanks,
grant
>
> Jeff
>
>
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: Andi Kleen @ 2006-06-14 5:18 UTC (permalink / raw)
To: David Miller; +Cc: lkml, jheffner, torvalds, linux-kernel, netdev
In-Reply-To: <20060613.142603.48825062.davem@davemloft.net>
> Also, as John Heffner mentioned, even if we could detect the broken
> boxes you can't just "turn off window scaling" after it's been
> negotiated. It's immutably active for the entire connection once
> enabled.
In theory you could set a bit in the dst entry and not use it next time
you connect to that host. That would be ok for web browsing at least
when creates new connections all the time.
But it's unclear how to even detect this situation reliably
e.g. you don't want to disable it just because there was a bit of
packet loss on a connection to a particular host earlier and there
is no clear heuristic to detect that this particular problem happened.
> So the broken boxes, which to be honest are few and far between these
> days, need to go, they really do.
Agreed.
-Andi
^ permalink raw reply
* Re: How can we make more use of memory for TCP properly?
From: Andi Kleen @ 2006-06-14 5:20 UTC (permalink / raw)
To: Kumiko Ono; +Cc: netdev
In-Reply-To: <448F323A.7000005@cs.columbia.edu>
> Accorting to TCP man page, the kernel calculates the values of
> sysctl_tcp_mem depending on available physical memory at boot time.
> I added 2GB RAM to a machine that had 2GB, and then it has 4GB RAM now.
> However, the value of sysctl_tcp_mem[2] has not changed from 196608
> (pages). The machine is running at Linux 2.6.16.5 i686 Intel(R)
> Pentium(R) 4 CPU 3.06GHz.
TCP can only use low memory for this which is limited to around 900MB
on 32bit systems. 64bit CPUs don't have this problem.
-Andi
^ permalink raw reply
* tcp_slow_start_after_idle
From: David Miller @ 2006-06-14 5:35 UTC (permalink / raw)
To: netdev; +Cc: zach.brown, jheffner
Bringing back up this old topic:
http://marc.theaimsgroup.com/?l=linux-netdev&m=114564962420171&w=2
I've decided to add this tunable to the net-2.6.18 tree, patch below.
The more I think about it, allowing it to be turned off is
reasonable, but it will be left on by default.
diff-tree 1cd14da556199b2827a92f1eaa9d3e8411c2b68d (from 2fa95182e211572e998c7d1f906aa74fb119b025)
Author: David S. Miller <davem@sunset.davemloft.net>
Date: Tue Jun 13 22:33:04 2006 -0700
[TCP]: Add tcp_slow_start_after_idle sysctl.
A lot of people have asked for a way to disable tcp_cwnd_restart(),
and it seems reasonable to add a sysctl to do that.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f12007b..d46338a 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -362,6 +362,13 @@ tcp_workaround_signed_windows - BOOLEAN
not receive a window scaling option from them.
Default: 0
+tcp_slow_start_after_idle - BOOLEAN
+ If set, provide RFC2861 behavior and time out the congestion
+ window after an idle period. An idle period is defined at
+ the current RTO. If unset, the congestion window will not
+ be timed out after an idle period.
+ Default: 1
+
IP Variables:
ip_local_port_range - 2 INTEGERS
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 98338ed..cee944d 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -405,6 +405,7 @@ enum
NET_TCP_BASE_MSS=114,
NET_IPV4_TCP_WORKAROUND_SIGNED_WINDOWS=115,
NET_TCP_DMA_COPYBREAK=116,
+ NET_TCP_SLOW_START_AFTER_IDLE=117,
};
enum {
diff --git a/include/net/tcp.h b/include/net/tcp.h
index de88c54..bfc71f9 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -227,6 +227,7 @@ extern int sysctl_tcp_abc;
extern int sysctl_tcp_mtu_probing;
extern int sysctl_tcp_base_mss;
extern int sysctl_tcp_workaround_signed_windows;
+extern int sysctl_tcp_slow_start_after_idle;
extern atomic_t tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index e7fb665..ce4cd5f 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -690,6 +690,14 @@ ctl_table ipv4_table[] = {
.proc_handler = &proc_dointvec
},
#endif
+ {
+ .ctl_name = NET_TCP_SLOW_START_AFTER_IDLE,
+ .procname = "tcp_slow_start_after_idle",
+ .data = &sysctl_tcp_slow_start_after_idle,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec
+ },
{ .ctl_name = 0 }
};
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 743016b..be6d929 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -59,6 +59,9 @@ int sysctl_tcp_tso_win_divisor = 3;
int sysctl_tcp_mtu_probing = 0;
int sysctl_tcp_base_mss = 512;
+/* By default, RFC2861 behavior. */
+int sysctl_tcp_slow_start_after_idle = 1;
+
static void update_send_head(struct sock *sk, struct tcp_sock *tp,
struct sk_buff *skb)
{
@@ -138,7 +141,8 @@ static void tcp_event_data_sent(struct t
struct inet_connection_sock *icsk = inet_csk(sk);
const u32 now = tcp_time_stamp;
- if (!tp->packets_out && (s32)(now - tp->lsndtime) > icsk->icsk_rto)
+ if (sysctl_tcp_slow_start_after_idle &&
+ (!tp->packets_out && (s32)(now - tp->lsndtime) > icsk->icsk_rto))
tcp_cwnd_restart(sk, __sk_dst_get(sk));
tp->lsndtime = now;
^ permalink raw reply related
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-14 6:07 UTC (permalink / raw)
To: Chase Venters; +Cc: netdev, linux-kernel
In-Reply-To: <200606131953.42002.chase.venters@clientec.com>
Chase,
On Tue, 13 Jun 2006, Chase Venters wrote:
>
> > I don't think that it is fair to say that an unstable API/ABI, in of
> > itself, provides an incentive to open an existing proprietary driver.
>
> Sure it does, depending on your perspective and what you're willing to
> consider. The lack of a stable API/ABI means that if you don't want to have
> to do work tracking the kernel, you should push to have your drivers merged.
>
More work must be done to track the kernel before they are merged, thus
purposeless API changes, or unnecessary use of EXPORT_SYMBOL_GPL impedes
merging
Not all useful kernel modules will nor should be merged GPL or not.
I think that a policy that intentionally makes it hard for proprietary
modules to be developed defeats the purpose of ultimate opening and merging.
It might end up causing something like iBCS, LinuxABI, SVR D3DK, or ODI to
flourish obviating the principal goal.
The interface currently under discussion is ultimately derived from the BSD
socket-protocol interface, and IMHO should be EXPORT_SYMBOL instead of
EXPORT_SYMBOL_GPL, if only because using _GPL serves no purpose here and can
be defeated with 3 or 4 obvious (and probably existing) lines of code. I
wrote similar wrappers for STREAMS TPI to Linux NET4 interface instead of
using pointers directly quite a few years ago. I doubt I was the first.
There is nothing really so novel here that it deserves _GPL.
^ permalink raw reply
* [PATCH 1/2] 8139cp: fix eeprom read command length
From: Philip Craig @ 2006-06-14 6:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
The read command for the 93C46/93C56 EEPROMS should be 3 bits plus
the address. This doesn't appear to affect the operation of the
read command, but similar errors for write commands do cause failures.
Signed-off-by: Philip Craig <philipc@snapgear.com>
Index: linux-2.6.17-rc6/drivers/net/8139cp.c
===================================================================
--- linux-2.6.17-rc6.orig/drivers/net/8139cp.c 2006-06-14 16:02:00.000000000 +1000
+++ linux-2.6.17-rc6/drivers/net/8139cp.c 2006-06-14 16:03:29.000000000 +1000
@@ -1628,7 +1628,7 @@ static int read_eeprom (void __iomem *io
eeprom_delay ();
/* Shift the read command bits out. */
- for (i = 4 + addr_len; i >= 0; i--) {
+ for (i = 3 + addr_len - 1; i >= 0; i--) {
int dataval = (read_cmd & (1 << i)) ? EE_DATA_WRITE : 0;
writeb (EE_ENB | dataval, ee_addr);
eeprom_delay ();
^ permalink raw reply
* [PATCH 2/2] 8139cp: add ethtool eeprom support
From: Philip Craig @ 2006-06-14 6:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Implement the ethtool eeprom operations for the 8139cp driver.
Tested on x86 and big-endian ARM.
Signed-off-by: Philip Craig <philipc@snapgear.com>
Index: linux-2.6.17-rc6/drivers/net/8139cp.c
===================================================================
--- linux-2.6.17-rc6.orig/drivers/net/8139cp.c 2006-06-14 15:59:26.000000000 +1000
+++ linux-2.6.17-rc6/drivers/net/8139cp.c 2006-06-14 15:59:53.000000000 +1000
@@ -401,6 +401,11 @@ static void cp_clean_rings (struct cp_pr
#ifdef CONFIG_NET_POLL_CONTROLLER
static void cp_poll_controller(struct net_device *dev);
#endif
+static int cp_get_eeprom_len(struct net_device *dev);
+static int cp_get_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *data);
+static int cp_set_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *data);
static struct pci_device_id cp_pci_tbl[] = {
{ PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139,
@@ -1577,6 +1582,9 @@ static struct ethtool_ops cp_ethtool_ops
.get_strings = cp_get_strings,
.get_ethtool_stats = cp_get_ethtool_stats,
.get_perm_addr = ethtool_op_get_perm_addr,
+ .get_eeprom_len = cp_get_eeprom_len,
+ .get_eeprom = cp_get_eeprom,
+ .set_eeprom = cp_set_eeprom,
};
static int cp_ioctl (struct net_device *dev, struct ifreq *rq, int cmd)
@@ -1612,24 +1620,32 @@ static int cp_ioctl (struct net_device *
#define eeprom_delay() readl(ee_addr)
/* The EEPROM commands include the alway-set leading bit. */
+#define EE_EXTEND_CMD (4)
#define EE_WRITE_CMD (5)
#define EE_READ_CMD (6)
#define EE_ERASE_CMD (7)
-static int read_eeprom (void __iomem *ioaddr, int location, int addr_len)
-{
- int i;
- unsigned retval = 0;
- void __iomem *ee_addr = ioaddr + Cfg9346;
- int read_cmd = location | (EE_READ_CMD << addr_len);
+#define EE_EWDS_ADDR (0)
+#define EE_WRAL_ADDR (1)
+#define EE_ERAL_ADDR (2)
+#define EE_EWEN_ADDR (3)
+
+#define CP_EEPROM_MAGIC PCI_DEVICE_ID_REALTEK_8139
+static void eeprom_cmd_start(void __iomem *ee_addr)
+{
writeb (EE_ENB & ~EE_CS, ee_addr);
writeb (EE_ENB, ee_addr);
eeprom_delay ();
+}
+
+static void eeprom_cmd(void __iomem *ee_addr, int cmd, int cmd_len)
+{
+ int i;
- /* Shift the read command bits out. */
- for (i = 3 + addr_len - 1; i >= 0; i--) {
- int dataval = (read_cmd & (1 << i)) ? EE_DATA_WRITE : 0;
+ /* Shift the command bits out. */
+ for (i = cmd_len - 1; i >= 0; i--) {
+ int dataval = (cmd & (1 << i)) ? EE_DATA_WRITE : 0;
writeb (EE_ENB | dataval, ee_addr);
eeprom_delay ();
writeb (EE_ENB | dataval | EE_SHIFT_CLK, ee_addr);
@@ -1637,6 +1653,33 @@ static int read_eeprom (void __iomem *io
}
writeb (EE_ENB, ee_addr);
eeprom_delay ();
+}
+
+static void eeprom_cmd_end(void __iomem *ee_addr)
+{
+ writeb (~EE_CS, ee_addr);
+ eeprom_delay ();
+}
+
+static void eeprom_extend_cmd(void __iomem *ee_addr, int extend_cmd,
+ int addr_len)
+{
+ int cmd = (EE_EXTEND_CMD << addr_len) | (extend_cmd << (addr_len - 2));
+
+ eeprom_cmd_start(ee_addr);
+ eeprom_cmd(ee_addr, cmd, 3 + addr_len);
+ eeprom_cmd_end(ee_addr);
+}
+
+static u16 read_eeprom (void __iomem *ioaddr, int location, int addr_len)
+{
+ int i;
+ u16 retval = 0;
+ void __iomem *ee_addr = ioaddr + Cfg9346;
+ int read_cmd = location | (EE_READ_CMD << addr_len);
+
+ eeprom_cmd_start(ee_addr);
+ eeprom_cmd(ee_addr, read_cmd, 3 + addr_len);
for (i = 16; i > 0; i--) {
writeb (EE_ENB | EE_SHIFT_CLK, ee_addr);
@@ -1648,13 +1691,125 @@ static int read_eeprom (void __iomem *io
eeprom_delay ();
}
- /* Terminate the EEPROM access. */
- writeb (~EE_CS, ee_addr);
- eeprom_delay ();
+ eeprom_cmd_end(ee_addr);
return retval;
}
+static void write_eeprom(void __iomem *ioaddr, int location, u16 val,
+ int addr_len)
+{
+ int i;
+ void __iomem *ee_addr = ioaddr + Cfg9346;
+ int write_cmd = location | (EE_WRITE_CMD << addr_len);
+
+ eeprom_extend_cmd(ee_addr, EE_EWEN_ADDR, addr_len);
+
+ eeprom_cmd_start(ee_addr);
+ eeprom_cmd(ee_addr, write_cmd, 3 + addr_len);
+ eeprom_cmd(ee_addr, val, 16);
+ eeprom_cmd_end(ee_addr);
+
+ eeprom_cmd_start(ee_addr);
+ for (i = 0; i < 20000; i++)
+ if (readb(ee_addr) & EE_DATA_READ)
+ break;
+ eeprom_cmd_end(ee_addr);
+
+ eeprom_extend_cmd(ee_addr, EE_EWDS_ADDR, addr_len);
+}
+
+static int cp_get_eeprom_len(struct net_device *dev)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ int size;
+
+ spin_lock_irq(&cp->lock);
+ size = read_eeprom(cp->regs, 0, 8) == 0x8129 ? 256 : 128;
+ spin_unlock_irq(&cp->lock);
+
+ return size;
+}
+
+static int cp_get_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *data)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ unsigned int addr_len;
+ u16 val;
+ u32 offset = eeprom->offset >> 1;
+ u32 len = eeprom->len;
+ u32 i = 0;
+
+ eeprom->magic = CP_EEPROM_MAGIC;
+
+ spin_lock_irq(&cp->lock);
+
+ addr_len = read_eeprom(cp->regs, 0, 8) == 0x8129 ? 8 : 6;
+
+ if (eeprom->offset & 1) {
+ val = read_eeprom(cp->regs, offset, addr_len);
+ data[i++] = (u8)(val >> 8);
+ offset++;
+ }
+
+ while (i < len - 1) {
+ val = read_eeprom(cp->regs, offset, addr_len);
+ data[i++] = (u8)val;
+ data[i++] = (u8)(val >> 8);
+ offset++;
+ }
+
+ if (i < len) {
+ val = read_eeprom(cp->regs, offset, addr_len);
+ data[i] = (u8)val;
+ }
+
+ spin_unlock_irq(&cp->lock);
+ return 0;
+}
+
+static int cp_set_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *data)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ unsigned int addr_len;
+ u16 val;
+ u32 offset = eeprom->offset >> 1;
+ u32 len = eeprom->len;
+ u32 i = 0;
+
+ if (eeprom->magic != CP_EEPROM_MAGIC)
+ return -EINVAL;
+
+ spin_lock_irq(&cp->lock);
+
+ addr_len = read_eeprom(cp->regs, 0, 8) == 0x8129 ? 8 : 6;
+
+ if (eeprom->offset & 1) {
+ val = read_eeprom(cp->regs, offset, addr_len) & 0xff;
+ val |= (u16)data[i++] << 8;
+ write_eeprom(cp->regs, offset, val, addr_len);
+ offset++;
+ }
+
+ while (i < len - 1) {
+ val = (u16)data[i++];
+ val |= (u16)data[i++] << 8;
+ write_eeprom(cp->regs, offset, val, addr_len);
+ offset++;
+ }
+
+ if (i < len) {
+ val = read_eeprom(cp->regs, offset, addr_len) & 0xff00;
+ val |= (u16)data[i];
+ write_eeprom(cp->regs, offset, val, addr_len);
+ }
+
+ spin_unlock_irq(&cp->lock);
+ return 0;
+}
+
/* Put the board into D3cold state and wait for WakeUp signal */
static void cp_set_d3_state (struct cp_private *cp)
{
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Chase Venters @ 2006-06-14 7:58 UTC (permalink / raw)
To: bidulock; +Cc: netdev, linux-kernel
In-Reply-To: <20060614000710.C7232@openss7.org>
On Wednesday 14 June 2006 01:06, Brian F. G. Bidulock wrote:
>
> The interface currently under discussion is ultimately derived from the BSD
> socket-protocol interface, and IMHO should be EXPORT_SYMBOL instead of
> EXPORT_SYMBOL_GPL, if only because using _GPL serves no purpose here and
> can be defeated with 3 or 4 obvious (and probably existing) lines of code.
> I wrote similar wrappers for STREAMS TPI to Linux NET4 interface instead of
> using pointers directly quite a few years ago. I doubt I was the first.
> There is nothing really so novel here that it deserves _GPL.
I mentioned that I don't have any particular opinion on the BSD socket API in
this discussion. All that I'm speaking of here is a property of licensing.
I've watched a lot of what has happened with binary drivers. You'll find in
the LKML archives plenty of lengthy discussions about whether or not binary
drivers are allowed under the GPL. If I were to guess, there is still
disagreement. Although some hardware support could improve, we thankfully
seem to have some kind of an equilibrium capable of supporting lots of users.
One point I remember coming up in the discussion was that the
EXPORT_SYMBOL()/EXPORT_SYMBOL_GPL() split was a compromise of sorts.
Interfaces that were needed to support users would reasonably be placed under
EXPORT_SYMBOL(). By contrast, EXPORT_SYMBOL_GPL() would indicate
functionality that would only seem to be used by derived works. It implies
that any code using it should probably be GPL as well.
I don't raise this in an attempt to belittle anything people are working on.
It's an observation about the ecosystem - Linux in the 2.6 series has seen a
great amount of corporate contribution in terms of enhancing what the kernel
is capable of doing. GPL, I believe, encourages this.
Thanks,
Chase
^ permalink raw reply
* Re: 2.6.17: networking bug??
From: Daniel Drake @ 2006-06-14 8:09 UTC (permalink / raw)
To: Mark Lord; +Cc: John Heffner, Linus Torvalds, Linux Kernel, netdev, davem
In-Reply-To: <448F0D4B.30201@rtr.ca>
Mark Lord wrote:
> Further to this, the current behaviour is badly unpredictable.
>
> A machine could be working perfectly, not (noticeably) affected
> by this bug. And then the user adds another stick of RAM to it.
This "bug" already existed in 2.6.16 to a certain extent: you were
losing out on a lot of TCP performance. Go back to 2.6.7, measure TCP
performance, and you'll probably find it was significantly better.
Also, there aren't that many broken end-points out there.
www.everymac.com loads fine for me and does not ignore the window scale
factor.
The problem in your case is a broken router in the middle. I had the
same problem: certain sites would not load, but there is absolutely
nothing wrong with the servers that run these sites:
http://marc.theaimsgroup.com/?l=linux-netdev&m=114478312100641&w=2
I contacted my ISP and informed them of the issue. They fixed it
nationwide within a few weeks. You might try confirming that your
problem only applies to HTTP like mine did (ISP runs some lame
transparent webcaches), and it was a bug in the software there (NetApp).
We already had the "some routers are broken, should we do anything"
discussion back at the time of 2.6.8:
http://lwn.net/Articles/92727/
Daniel
^ permalink raw reply
* Re: [RFC/PATCH 1/2] in-kernel sockets API
From: Brian F. G. Bidulock @ 2006-06-14 9:28 UTC (permalink / raw)
To: Chase Venters; +Cc: netdev, linux-kernel
In-Reply-To: <200606140258.30302.chase.venters@clientec.com>
Chase,
On Wed, 14 Jun 2006, Chase Venters wrote:
>
> One point I remember coming up in the discussion was that the
> EXPORT_SYMBOL()/EXPORT_SYMBOL_GPL() split was a compromise of sorts.
> Interfaces that were needed to support users would reasonably be placed under
> EXPORT_SYMBOL(). By contrast, EXPORT_SYMBOL_GPL() would indicate
> functionality that would only seem to be used by derived works. It implies
> that any code using it should probably be GPL as well.
The difficulty with EXPORT_SYMBOL_GPL() as I see it that it reached farther
than the GPL. GPL does not impact non-derived works, which can be licensed
under any terms their authors see fit. Whereas, EXPORT_SYMBOL_GPL() requires
a non-derived work to declare a GPL license to even use it. If you subscribe
to the FSF view of derived work (just linking is a derivation) then I suppose
you would support the EXPORT_SYMBOL_GPL(). IANAL, but I don't believe that
TRIPS nor Berne Convention case law supports the FSF view. Linus' statements
in the COPYING file take a different view: that simple use of a technical
interface is not necessarily (in itself) derivation.
Now, I understand the use of EXPORT_SYMBOL() vs. EXPORT_SYMBOL_GPL() to allow
authors to differ on this idea. But, in the case in point, the function
pointers can be accessed by merely including the appropriate header files.
Changing a the wrapper access to them to EXPORT_SYMBOL_GPL() strikes me as
similar to changing kmalloc() from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL().
Understand that all exported symbols, regardless of licensing or modversions
or whatever, are available in the kernel boot image and can be linked to by
any module at any time. That is, those that would abuse the concept of
derivation will not be impeded by EXPORT_SYMBOL_GPL(). (Rip the symbol from
the kernel image, write a thin GPL'ed module that aliases the symbol and the
exports it again as EXPORT_SYMBOL() without module versioning, copy the lines
of code into the proprietary module, reversing the order of arbitrary lines,
etc.)
In any case, all it serves to do is to punish honest non-derivative works not
published compatible with the GPL.
What I resist is the apparent attempt to change these symbols to _GPL as some
matter of general policy in this case contrary to the author's original
intentions as expressed in the original patch submission, and without the
author of the interface being wrappered jumping up an screaming that his code
was under strict FSF linking-is-derivation GPL (in which case we could have
had a good discussion on whether Linux NET4 is actually a derivative work of
BSD 4.4 Lite which was licensed under the "old" BSD license, incompatible with
the GPL ;)
As a general policy I would say make it EXPORT_SYMBOL() unless the author of
the patch (derivation) or author of the original (derived) code dictates that
it be EXPORT_SYMBOL_GPL().
Ok, I'll shut up now... ...really.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox