* Re: [PATCH] use mmiowb in tg3_poll
From: Jesse Barnes @ 2005-05-31 16:45 UTC (permalink / raw)
To: hadi; +Cc: Arthur Kepner, Lennert Buytenhek, netdev, gnb
In-Reply-To: <1117544022.6134.54.camel@localhost.localdomain>
On Tuesday, May 31, 2005 5:53 am, jamal wrote:
> Did i read correctly that your reads are about 2x more expensive than
> the writes?
The test above just measures the difference between using a full PIO
read to ensure write ordering vs. the lighter weight mmiowb call. As
for your question though, non-relaxed reads are very expensive on the
Altix platform due to its highly distributed NUMA I/O architecture.
The _relaxed variants can be quite fast however, and can be used
anytime a PIO read doesn't imply anything about previous DMA
transactions.
Jesse
^ permalink raw reply
* Patch for "ETH_P_ALL_NO_NIT"
From: Atkinson Stephen-G19998 @ 2005-05-31 16:38 UTC (permalink / raw)
To: netdev
I would like to be able to receive all packets (regardless of type) on
a given net_device. One way to do this would be to use ETH_P_ALL
however, ETH_P_ALL has two meanings, 1) receive all packets and 2) behave
as a "NIT" (Network Interface Tap?). The NIT functionality causes packets
transmitted on the net_device in question to be "received" by an ETH_P_ALL
socket, unless the packet was sent by that socket.
So, I'd like to propose a new ethernet type (ETH_P_ALL_NO_NIT) which
would behave like ETH_P_ALL without the side effects of NIT.
I've included a patch for ETH_P_ALL_NO_NIT below.
Comments?
Signed-off-by: Steve Atkinson <satkinson@motorola.com>
--- linux-2.6.9_orig/include/linux/if_ether.h 2004-10-18 17:54:37.000000000 -0400
+++ linux-2.6.9/include/linux/if_ether.h 2005-05-31 10:32:50.000000000 -0400
@@ -91,6 +91,7 @@
#define ETH_P_IRDA 0x0017 /* Linux-IrDA */
#define ETH_P_ECONET 0x0018 /* Acorn Econet */
#define ETH_P_HDLC 0x0019 /* HDLC frames */
+#define ETH_P_ALL_NO_NIT 0x0020 /* Every packet but DON'T ENABLE netdev_nit */
/*
* This is an Ethernet frame header.
--- linux-2.6.9_orig/net/core/dev.c 2004-10-18 17:54:08.000000000 -0400
+++ linux-2.6.9/net/core/dev.c 2005-05-31 10:56:50.000000000 -0400
@@ -276,7 +276,10 @@
if (pt->type == htons(ETH_P_ALL)) {
netdev_nit++;
list_add_rcu(&pt->list, &ptype_all);
- } else {
+ } else if(pt->type == htons(ETH_P_ALL_NO_NIT)) {
+ list_add_rcu(&pt->list, &ptype_all);
+ }
+ else {
hash = ntohs(pt->type) & 15;
list_add_rcu(&pt->list, &ptype_base[hash]);
}
@@ -310,9 +313,11 @@
if (pt->type == htons(ETH_P_ALL)) {
netdev_nit--;
head = &ptype_all;
- } else
+ } else if (pt->type == htons(ETH_P_ALL_NO_NIT)) {
+ head = &ptype_all;
+ } else {
head = &ptype_base[ntohs(pt->type) & 15];
-
+ }
list_for_each_entry(pt1, head, list) {
if (pt == pt1) {
list_del_rcu(&pt->list);
@@ -1072,9 +1077,10 @@
/* Never send packets back to the socket
* they originated from - MvS (miquels@drinkel.ow.org)
*/
- if ((ptype->dev == dev || !ptype->dev) &&
- (ptype->af_packet_priv == NULL ||
- (struct sock *)ptype->af_packet_priv != skb->sk)) {
+ if ( (ptype->type != ETH_P_ALL_NO_NIT) &&
+ (ptype->dev == dev || !ptype->dev) &&
+ (ptype->af_packet_priv == NULL ||
+ (struct sock *)ptype->af_packet_priv != skb->sk)) {
struct sk_buff *skb2= skb_clone(skb, GFP_ATOMIC);
if (!skb2)
break;
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: Thomas Graf @ 2005-05-31 16:13 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, David S. Miller
In-Reply-To: <1117551561.6279.2.camel@localhost.localdomain>
* Jamal Hadi Salim <1117551561.6279.2.camel@localhost.localdomain> 2005-05-31 10:59
> netdevice ->
> L2 config stuff
> config stuff
> more config stuff
> even more config stuff
> ..
> ..
> netdevice protocol config:
> -> v4 specific (struct in_device)
> ----> IPV4 addresses (ifa_list), ARP params(arp_parms),etc
> -> v6 specific (struct inet6_dev)
> ----> IPV6 addresses(addr_list), ndisc params (nd_parms), etc
Absolutely.
> I think we are agreeing _not_ to configure ifa_list, arp_parms etc
> via devconfig. Leave these to their already existing config paths.
arp_parms is just a reference to the corresponding device specific
parameter set of the "arp_cache" neighbour table. Maybe I've been
misunderstanding you throughout all your posts or maybe I've a
wrong understanding of the neighbour code in general. As far as I
understand it:
1) The actual neighbour implementation registers a new neighbour
table by calling neigh_table_init() with the proposed default
configuration for this table. This also includes the default
parameter set used to derive device specific parameter sets
later on, e.g. arp_tbl.
2) Upon the creation of a inet_device/... a new parameter set
is allocated that derives the initial parameter values from
the default parameter set. This parameter set is stored
in in_dev->arp_parms and linked in a list of parameter sets
in the neighbour table (neightbl->parms).
3) When a new neighbour is created the core neighbour code
will assign the default parameter set of the table to
the neighbour and increments its refcnt. It then calls
the constructor of arp,ndisc,... which replaces the
parameter set just assigned with the one in
in_dev->arp_parms which is the parameter set.
So what I propose is to have the neighbour table parameters,
e.g. everything in arp_tbl be distributed over RTM_NEIGHTBL
and put the device specific parameters into devconfig,
e.g. in_dev->arp_parms.
> In the case of devconfig:
> What i am suggesting is to put some identifier that can be used
> to access lets say one or more arp_parms. This way when i dump
> the devconfig i should be able to see "connected to arp table 1".
> I should then be able to say dump arp table 1.
OK, this is possible with either way. I don't worry about this.
> The directionality as i see it is:
>
> netdevice --> arp/ndisc table(s)
> [And the binding/stiching of those tables is via inxx_devyy].
Absolutely, more specific:
netdevice -> inet_device -> parameter set -> neighbour table
or:
neighbour table -> list of parameter sets -> netdevice
both ways are possible right now.
^ permalink raw reply
* Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way)
From: Grant Grundler @ 2005-05-31 15:38 UTC (permalink / raw)
To: Michael Chan; +Cc: David S. Miller, Peter Chubb, netdev
In-Reply-To: <B1508D50A0692F42B217C22C02D84972020F3CED@NT-IRVA-0741.brcm.ad.broadcom.com>
On Wed, Dec 22, 2004 at 04:02:44PM -0800, Michael Chan wrote:
> David, While the 2nd patch or something similar should be applied, I
> think the underlying cause of tg3_readphy() returning error should be
> further investigated.
>
> Peter, if you provide more information, such as registers MAC_MI_MODE
> (0x454) and MAC_MI_COM (0x44c) after the failure, I can look into it.
Michael,
Peter bounced this email to me after we talked about issues he was
having with the rx8620 (HP 16-way ia64, sx1000 chipset) "IOX Core LAN".
It sounded like the same problem I tracked down with rx8620 IOX Core LAN
in March. Here is the summary :
| In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting
| programmed and how to determine what to program into LED_CTRL. The new
| code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write
| to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was
| saying MODE_MAC (0x0) and that doesn't work.
HP is working with broadcom to figure out how to update the firmware.
Ben Malavazi <malavazi@cup.hp.com> is talking with
Pratapa Reddy Vaka <pvaka@broadcom.com>
'Johnny Ho' <jho@broadcom.com>
I'm not sure they are aware of the root cause. But they can probably
provide you with the process to update the onboard firmware image
should this come up again.
b57diag is one way. HP also has an FCUPDATE tool that's a bit
less dangerous/more user friendly. FCUPDATE needs a newer EFI
driver to operate correctly so it's non-trivial to get started as well.
I'm hoping one of the two can be scripted to auto update.
I'm told rx5670 Core LAN firmware was the original image used by the
rx8620 IOX Core LAN team and may also exhibit the same problem.
I've not heard any trouble reports so far on rx5670 but please
forward them to me if you do.
Please do NOT apply the appended patch - it's just a temp workaround
until the owners of the "IOX Core LAN" and Broadcom can get their
act together. The patch appended below is for RHEL3u4 (tg3 v3.10RH)
but should apply (with fuzz) to any tg3 v3.4 or later.
The patch adds a "quirk" (bug workaround) to overide the SRAM value
and use LED_CTRL_MODE_PHY_1 (0x00000800) instead. This results in
LNK3_LED_MODE (0x2) getting written to MII_TG3_EXT_CTRL (0x10) for
bcm5700/5701 chips. I do NOT understand why programming the
MII_TG3_EXT_CTRL register differently will change how auto-negotiation
works.
hth,
grant
--- orig/drivers/net/tg3.c 2005-03-19 21:39:25.000000000 -0600
+++ ggg/drivers/net/tg3.c 2005-03-20 13:17:50.000000000 -0600
@@ -7090,9 +7089,20 @@ static int __devinit tg3_phy_probe(struc
};
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
- GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) &&
- tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL)
- tp->led_ctrl = LED_CTRL_MODE_PHY_2;
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701)) {
+ /* Quirks: firmware is wrong */
+ switch (tp->pdev->subsystem_vendor) {
+ case PCI_VENDOR_ID_DELL:
+ tp->led_ctrl = LED_CTRL_MODE_PHY_2;
+ break;
+
+ case PCI_VENDOR_ID_HP:
+ /* HP IOX Core Lan 1000Base-T [A7109AX] */
+ if (tp->pdev->subsystem_device == 0x12c1)
+ tp->led_ctrl = LED_CTRL_MODE_PHY_1;
+ break;
+ }
+ }
if (((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703) ||
(GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) ||
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: Jamal Hadi Salim @ 2005-05-31 14:59 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, David S. Miller
In-Reply-To: <20050531131747.GF15391@postel.suug.ch>
On Tue, 2005-31-05 at 15:17 +0200, Thomas Graf wrote:
>
> OK, so your idevxxx is a kind of container for various configurable
> blocks that logically belong to a inetdevice and a device specific
> parameter set for a neighbour table would one of these blocks?
>
Essentialy just in_device and inet6_dev
> I think this is appropriate for NDTA_PARMS, e.g. there might be
> multiple of such neighbour table parameter blocks per inetdevice
> identified by the name of the neighbour table. You certainly have
> a good point there, I see two minor drawbacks though: a) where
> do we put these parameter blocks if it doesn't belong to a
> inetdevice? and b) it makes collecting the complete configuration
> of a neighbour table complicated. Nevertheless, I think I can
> agree on this.
>
To recap:
netdevice ->
L2 config stuff
config stuff
more config stuff
even more config stuff
..
..
netdevice protocol config:
-> v4 specific (struct in_device)
----> IPV4 addresses (ifa_list), ARP params(arp_parms),etc
-> v6 specific (struct inet6_dev)
----> IPV6 addresses(addr_list), ndisc params (nd_parms), etc
I think we are agreeing _not_ to configure ifa_list, arp_parms etc
via devconfig. Leave these to their already existing config paths.
In the case of devconfig:
What i am suggesting is to put some identifier that can be used
to access lets say one or more arp_parms. This way when i dump
the devconfig i should be able to see "connected to arp table 1".
I should then be able to say dump arp table 1.
If it is too complex an idea we can drop it.
The defaults should stay as you say (and as they exist today) in the
arp block.
> > I agree that we should leave the neighbor table-specific knobs out of
> > devconfig.
>
> OK, so we leave RTM_NEIGHTBL_* as-is but move the device specific
> parameter sets into devconfig? i.e. RTM_NEIGHTBL_* will cover:
>
> * the core neighbour table configuration (key-len, entry-size,
> last-flush, gc thresholds, gc interval, hash settings, etc.)
> * the default parameter set
> * neighbour table statistics
>
Sounds reasonable.
And per device arp/ndisc is of course one of many
configurable parameters via devconfig.
>
> > It will help, though, for devconfig to have a single reference to the
> > "instance" of the table(perhaps a name or a even a 32 bit pointer
> > address) that a device uses (thefore maintaining the abstraction); but
> > since there is only one table for v4 and v6 anyways i suppose it is
> > implicitly assumed to be that one table.
>
> This kind of breaks the architecture, i'd rather have it the other
> way around, i.e. we hold a netdevice reference in each parameter set
> and when lookup a parameter set for a specific idevxxx we iterate
> through all neighbour tables and their paremter sets and compare
> ifindex.
The directionality as i see it is:
netdevice --> arp/ndisc table(s)
[And the binding/stiching of those tables is via inxx_devyy].
I dont have issues with arp pointing to netdevice as well, but I
thought ARP/ndisc already have ifindex reference?
cheers,
jamal
^ permalink raw reply
* Re: [2/5] ieee80211: ieee80211_device alignment fix and cleanup
From: Jiri Benc @ 2005-05-31 13:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: NetDev, jbohac
In-Reply-To: <4297E78A.4030906@pobox.com>
On Fri, 27 May 2005 23:37:46 -0400, Jeff Garzik wrote:
> 1) I am not convinced that the subclassing of net_device should be done
> in this manner. Read drivers/net/wan/hdlc_generic.c and .../pc300_drv.c
> for examples of how hdlc_device is handled.
We see two differences to the hdlc concept:
1. the driver private data is allocated together with the net_device and
ieee80211_device data;
2. ieee80211_device is passed to functions instead of net_device.
Allocating all the structures together just extends the concept of
net_device allocation. The advantage is that all the structures are
located close to each other in the memory which (hopefully) improves
cache performance.
Passing ieee80211_device seems to be more appropriate in this case,
since drivers will be accessing ieee80211 data far more frequently than
net_device data. For example, part of the plan is to integrate Wireless
Extensions into the ieee80211 layer -- for all the ioctl handlers, it
will be much more interesting to have the ieee80211_device passed to
them. Furthermore, driver writers will not be tempted to think that
net_device->priv points to _their_ private data (which the name
suggests, but is not true).
Or did you mean something different?
> 2) Please put all the new, protocol-layer functions
> ieee80211_type_trans(), ieee80211_change_mtu(), ieee80211_header(), etc.
> in their own file.
Will be posted in the next patch series.
> 3) Temporary or not, the following construct is simply not necessary.
> Modify the definition rather than repeating this two-call piece of code
> in multiple areas:
> ieee80211_priv(netdev_priv(dev));
As soon as we're done integrating WE into ieee80211, most of this will
disappear. But sure, we can add a ieee80211_priv_from_netdev (or so)
macro for now.
> 4) A low-level wireless hardware driver should look like other net
> drivers, and use the existing driver API. The low level driver should
> implement its own dev->hard_start_xmit().
> Certainly, the driver will make many calls to generic ieee80211_xxx
> functions to get things done.
Actually, hard_start_xmit has to do a lot of work regarding software
fragmentation, encryption, sequence numbering, etc. Sure, every driver
could call some ieee80211_prepare_to_xmit function in its own
hard_start_xmit, but we see no point in doing this as it would have to
be done by almost every driver. Drivers for very clever cards may
probably be an exception, but the risk is, that if they implement part
of the logic themselves, they will be more difficult to maintain as new
features are implemented in the ieee80211 layer. Furthermore, it is
against one of our premises ("the simpler card, the simpler driver").
We think that this concept of an "ieee80211 sublayer" has more
advantages than the concept of an "ieee80211 library". Do you have any
reasons why it should be the other way round?
Jiri Benc & Jirka Bohac
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: Thomas Graf @ 2005-05-31 13:17 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <1117543711.6134.48.camel@localhost.localdomain>
* jamal <1117543711.6134.48.camel@localhost.localdomain> 2005-05-31 08:48
> The neighbor code ought not be aware of devices; but whoever is
> configuring must be. By configuring i mean "stiching together" the
> different blocks (as in some netlink based program in user space). the
> idevxxx is a "stiching" construct - and therefore it may be aware of
> many other things that a standalone block doesnt. One could argue that
> the ifindex in a netdevice is also under the same class. The ARP, NDISC,
> netdevice, filters etc are the blocks being sown together.
> Most of the times these blocks are built together in a topology that a
> packet flows through.
OK, so your idevxxx is a kind of container for various configurable
blocks that logically belong to a inetdevice and a device specific
parameter set for a neighbour table would one of these blocks?
I think this is appropriate for NDTA_PARMS, e.g. there might be
multiple of such neighbour table parameter blocks per inetdevice
identified by the name of the neighbour table. You certainly have
a good point there, I see two minor drawbacks though: a) where
do we put these parameter blocks if it doesn't belong to a
inetdevice? and b) it makes collecting the complete configuration
of a neighbour table complicated. Nevertheless, I think I can
agree on this.
> I agree that we should leave the neighbor table-specific knobs out of
> devconfig.
OK, so we leave RTM_NEIGHTBL_* as-is but move the device specific
parameter sets into devconfig? i.e. RTM_NEIGHTBL_* will cover:
* the core neighbour table configuration (key-len, entry-size,
last-flush, gc thresholds, gc interval, hash settings, etc.)
* the default parameter set
* neighbour table statistics
> It will help, though, for devconfig to have a single reference to the
> "instance" of the table(perhaps a name or a even a 32 bit pointer
> address) that a device uses (thefore maintaining the abstraction); but
> since there is only one table for v4 and v6 anyways i suppose it is
> implicitly assumed to be that one table.
This kind of breaks the architecture, i'd rather have it the other
way around, i.e. we hold a netdevice reference in each parameter set
and when lookup a parameter set for a specific idevxxx we iterate
through all neighbour tables and their paremter sets and compare
ifindex.
^ permalink raw reply
* Re: [PATCH] use mmiowb in tg3_poll
From: jamal @ 2005-05-31 12:53 UTC (permalink / raw)
To: Arthur Kepner; +Cc: Lennert Buytenhek, netdev, jesse.barnes, gnb
In-Reply-To: <Pine.LNX.4.61.0505300925570.11645@linux.site>
On Mon, 2005-30-05 at 09:30 -0700, Arthur Kepner wrote:
> I quickly looked through the records that I have and, unfortunately,
> wasn't able to locate raw data. But I found some scrawlings in my
> notes which say the most recent measurements for an Altix are:
>
> i) PIO read latency ~ 2.4 usec
> ii) mmiowb() latency ~ 1.1 usec
>
In terms of CPU cycles, how many do the above compute to be?
The absolute time numbers you have are also useful for quantification
purposes.
Did i read correctly that your reads are about 2x more expensive than
the writes?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: jamal @ 2005-05-31 12:48 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050531114251.GC15391@postel.suug.ch>
On Tue, 2005-31-05 at 13:42 +0200, Thomas Graf wrote:
> > All "stuffs" (your bases is mine) accessible via in_devxx abstraction
> > should be devconfig configurable. I do concur that some of it may not
> > make sense - but that should be the exception rules...
> > Ok, lets say these tables are one such exception, but note:
> > In the future there could be multiple ARP tables for example (very
> > likely given all the virtualization approaches happening). In other
> > words different devices may point to different tables...
>
> Let's assume for a moment that there are no device specific parameters,
> just the default parameter set, e.g everything in the "arp_cache" block.
> According do your idea, everything would be part of a faked in_dev entry
> with ifindex==0 (or alike). We'd have the exact same issues as with
> RTM_NEIGHTBL, the requirement of unique table ids stays the same. There
> is one big difference though, what if we ever have neighbour tables which
> do not care about inet devices at all? Maybe some kind of new virtual
> devices for in-kernel communication? ;-> Sounds scary and not realistic,
An extra virtual device just to store the defaults will be overkill.
OTOH, a global allocated structure for defaults is ok. I think thats the
way it is done today.
> but my point is basically that neighbour tables itself have a global scope,
> the assignment to the device and device specific parameters is on the
> level of the neighbours itself. The connection to in_dev/... is one
> level higher with a scope of the relevant neighbour table. A neighbour
> table implementation is not required to support device specific
> parameters, the code neighbour code will always assign the default
> parameter set and leaves it up to the constructor of the implementation
> level to reassign a device specific parameter set. Which means that what
> the procfs and now also neightbl code does it kind of a hack anyway
> since the core neighbour code is not aware of device specific stuff
> anyway, all it does is provide an easy method to manage them in a
> efficient matter.
The neighbor code ought not be aware of devices; but whoever is
configuring must be. By configuring i mean "stiching together" the
different blocks (as in some netlink based program in user space). the
idevxxx is a "stiching" construct - and therefore it may be aware of
many other things that a standalone block doesnt. One could argue that
the ifindex in a netdevice is also under the same class. The ARP, NDISC,
netdevice, filters etc are the blocks being sown together.
Most of the times these blocks are built together in a topology that a
packet flows through.
> I would like to stay consistent to this architecture
> if possible to be able to follow every new additions.
>
> I hope my point is now clear, I wasn't so sure until now ;-> However,
> I think you have a good point, parameter sets have a strong relation
> to inet devices at the moment. If you still think that we should move
> _everything_ into a devconfig layer then I'll do it but I still support
> my initial prospoal.
>
I agree that we should leave the neighbor table-specific knobs out of
devconfig.
It will help, though, for devconfig to have a single reference to the
"instance" of the table(perhaps a name or a even a 32 bit pointer
address) that a device uses (thefore maintaining the abstraction); but
since there is only one table for v4 and v6 anyways i suppose it is
implicitly assumed to be that one table.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: Thomas Graf @ 2005-05-31 11:42 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <1117533847.6134.32.camel@localhost.localdomain>
* jamal <1117533847.6134.32.camel@localhost.localdomain> 2005-05-31 06:04
> Probably a good start. This would still be missing the gc thresholds
> etc, no?
Yes, this only includes the parts that I marked with 'X' and '?' below.
> > What about this, we move the device specific part into the new devconfig
> > layer but leave the main configuration, statistics, and gc parameters
> > in RTM_NEIGHTBL? i.e.
> >
> > arp_cache entries 2 reachable-time 23s 993msec retransmit-time 1s
> > key-len 4 entry-size 152 last-flush 55m 44s 572msec
> > gc threshold 128/512/1024 interval 30s chain-position 3
> > hash-rand 0x69650257/0x00000003 last-rand 1m 44s 571msec
> > ? refcnt 1 pending-queue-limit 3 proxy-delayed-queue-limit 64
> > ? num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3
> > ? min-age 1s base-reachable-time 30s stale-check-interval 1m
> > ? initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec
> > lookups 195 hits 190 failed 0 allocations 3 destroys 1
> > hash-grows 1 forced-gc-runs 0 periodic-gc-runs 910
> > rcv-unicast-probes 0 rcv-multicast-probes 0
> >
> > Xarp_cache<eth0> reachable-time 35s 967msec retransmit-time 1s
> > X refcnt 3 pending-queue-limit 3 proxy-delayed-queue-limit 64
> > X num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3
> > X min-age 1s base-reachable-time 30s stale-check-interval 1m
> > X initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec
> >
> >
> > Everything marked with X is clearly device specific so it will move.
> > Everything marked with '?' is the default parameter set, we can either
> > leave it or move it as well and put it under into a 'default' ifindex.
> > I don't care about the latter, either is fine with me.
> >
>
> All "stuffs" (your bases is mine) accessible via in_devxx abstraction
> should be devconfig configurable. I do concur that some of it may not
> make sense - but that should be the exception rules...
> Ok, lets say these tables are one such exception, but note:
> In the future there could be multiple ARP tables for example (very
> likely given all the virtualization approaches happening). In other
> words different devices may point to different tables...
Let's assume for a moment that there are no device specific parameters,
just the default parameter set, e.g everything in the "arp_cache" block.
According do your idea, everything would be part of a faked in_dev entry
with ifindex==0 (or alike). We'd have the exact same issues as with
RTM_NEIGHTBL, the requirement of unique table ids stays the same. There
is one big difference though, what if we ever have neighbour tables which
do not care about inet devices at all? Maybe some kind of new virtual
devices for in-kernel communication? ;-> Sounds scary and not realistic,
but my point is basically that neighbour tables itself have a global scope,
the assignment to the device and device specific parameters is on the
level of the neighbours itself. The connection to in_dev/... is one
level higher with a scope of the relevant neighbour table. A neighbour
table implementation is not required to support device specific
parameters, the code neighbour code will always assign the default
parameter set and leaves it up to the constructor of the implementation
level to reassign a device specific parameter set. Which means that what
the procfs and now also neightbl code does it kind of a hack anyway
since the core neighbour code is not aware of device specific stuff
anyway, all it does is provide an easy method to manage them in a
efficient matter. I would like to stay consistent to this architecture
if possible to be able to follow every new additions.
I hope my point is now clear, I wasn't so sure until now ;-> However,
I think you have a good point, parameter sets have a strong relation
to inet devices at the moment. If you still think that we should move
_everything_ into a devconfig layer then I'll do it but I still support
my initial prospoal.
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: jamal @ 2005-05-31 10:04 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050528120731.GP15391@postel.suug.ch>
Doesnt seem like i responded to this.
On Sat, 2005-28-05 at 14:07 +0200, Thomas Graf wrote:
> * jamal <1117244567.6251.34.camel@localhost.localdomain> 2005-05-27 21:42
> > On Fri, 2005-27-05 at 18:35 +0200, Thomas Graf wrote:
> >
> > > I do NOT agree on moving gc_ into this architecture as well,
> > > it doesn't belong there.
> >
> > Well, you do realize they are part of the in_dev ? ;->
>
> Huh? They cannot be device specific, there is only one gc
> per neighbour table. So even _iff_ there was a device specific
> setting it wouldn't make much sense ;->
>
I keep forgeting some of these tables are system wide.
But i think it doesnt matter as long as we comply to the abstration
thats in the kernel; in other words, config access is still via the
in_devxx. i.e if you supply any ifindex (since all devices _at the
moment_ point to the same ARP/ndisc table), it can be accessed and
configured.
> > I see a little main service header with ifindex always no different than
> > IFA or IFLINK etc followed by appropriate TLVs which are nested.
>
> I guess we could simply move NDTPA_PARMS into the devconfig family.
Probably a good start. This would still be missing the gc thresholds
etc, no?
> > Well, if you look at the structure there is no reason they should really
> > be separate; infact theres a comment:
> > -----------
> > struct neigh_parms parms;
> > /* HACK. gc_* shoul follow parms without a gap! */
> > int gc_interval;
> > int gc_thresh1;
> > int gc_thresh2;
> > ----------
>
> You do realize the reason for that comment? ;-> The author of
> the neighbour procfs code was simply too lazy to put these
> into a separate place so he introduced a nasty hack.
>
I think you are correct.
> What about this, we move the device specific part into the new devconfig
> layer but leave the main configuration, statistics, and gc parameters
> in RTM_NEIGHTBL? i.e.
>
> arp_cache entries 2 reachable-time 23s 993msec retransmit-time 1s
> key-len 4 entry-size 152 last-flush 55m 44s 572msec
> gc threshold 128/512/1024 interval 30s chain-position 3
> hash-rand 0x69650257/0x00000003 last-rand 1m 44s 571msec
> ? refcnt 1 pending-queue-limit 3 proxy-delayed-queue-limit 64
> ? num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3
> ? min-age 1s base-reachable-time 30s stale-check-interval 1m
> ? initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec
> lookups 195 hits 190 failed 0 allocations 3 destroys 1
> hash-grows 1 forced-gc-runs 0 periodic-gc-runs 910
> rcv-unicast-probes 0 rcv-multicast-probes 0
>
> Xarp_cache<eth0> reachable-time 35s 967msec retransmit-time 1s
> X refcnt 3 pending-queue-limit 3 proxy-delayed-queue-limit 64
> X num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3
> X min-age 1s base-reachable-time 30s stale-check-interval 1m
> X initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec
>
>
> Everything marked with X is clearly device specific so it will move.
> Everything marked with '?' is the default parameter set, we can either
> leave it or move it as well and put it under into a 'default' ifindex.
> I don't care about the latter, either is fine with me.
>
All "stuffs" (your bases is mine) accessible via in_devxx abstraction
should be devconfig configurable. I do concur that some of it may not
make sense - but that should be the exception rules...
Ok, lets say these tables are one such exception, but note:
In the future there could be multiple ARP tables for example (very
likely given all the virtualization approaches happening). In other
words different devices may point to different tables...
cheers,
jamal
^ permalink raw reply
* who
From: 王海 @ 2005-05-31 9:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1117532391.6134.13.camel@localhost.localdomain>
who [netdev]
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: jamal @ 2005-05-31 9:39 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050528161637.GT15391@postel.suug.ch>
On Sat, 2005-28-05 at 18:16 +0200, Thomas Graf wrote:
> * jamal <1117296041.19563.6.camel@localhost.localdomain> 2005-05-28 12:00
> > > I just tested both patches for about 30 minutes. Everything OK. Feel
> > > free to apply the patches.
> >
> > We have another problem. What tree is this against? Both patches have
> > failures patching against latest davem and linus git trees.
>
> It's against my davem-pending tree which should reflect the current
> state of davem's tree so they _should_ apply on his side. In this
> specific case you're probably missing the neighbour table patches.
Now you really have to send some swiss chocolate over ;->
It still doesnt apply to Davems latest tree.
> Basically I produce diffs this way:
>
> separate tree per patchset -> merge into testing tree ->
> testing period -. merge into $person-pending -> extraction
> of patches and submission.
>
Almost very close to what i do - which could be improved or you keep a
few hundred trees. Jeff Garzik (some email to netdev with a HOWTO ) was
talking about some new scheme where instead of trees you use branches of
the same tree. I didnt quiet follow his trick.
> I was trying to get some more quality control into my workflow,
> so I started testing patches for 3-4 weeks to avoid fallouts
> but apparently this is failing miserably at the moment due to
> some broken scripts of mine.
I think the problem in this case was you had already commited to that
tree your changes that you sent to Dave. And the tree you were using as
a base for generating the patch was only something you and Dave know
about.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks
From: James Morris @ 2005-05-31 4:15 UTC (permalink / raw)
To: jaegert; +Cc: netdev, chrisw, serue, latten, sds
In-Reply-To: <1116361671.5560.125.camel@dyn9002018177.watson.ibm.com>
On Tue, 17 May 2005, jaegert wrote:
Ok, my last review in this iteration.
> @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr
> x->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime;
> x->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime;
> }
> +
> + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1];
> + if (sec_ctx != NULL) {
> + if (security_xfrm_state_alloc(x, sec_ctx))
> + goto out;
You should propagate the return value of security_xfrm_state_alloc() here
by assigning it to err.
> -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o
> +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o
What about making nethooks.o (or whatever it'll be called) conditionally
compiled via CONFIG_SECURITY_NETWORK_XFRM ? (see netif.o)
> + * ISSUES:
> + * 1. Caching packets, so they are not dropped during negotiation
This needs to be done for IPsec in general, not sure what the status is.
> + * 2. Emulating a reasonable SO_PEERSEC across machines
This may not be too difficult if we limit this to connected TCP sockets.
> + * 3. Testing sk_policy setting with context
What does this mean?
Overall, this looks like a really good approach to the problem.
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply
* Re: [-mm patch] net/ieee80211/: remove pci.h #include's
From: Jouni Malinen @ 2005-05-31 1:22 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jgarzik, hostap, linux-kernel, netdev
In-Reply-To: <20050530205634.GQ10441@stusta.de>
On Mon, May 30, 2005 at 10:56:34PM +0200, Adrian Bunk wrote:
> I was wondering why editing pci.h triggered the rebuild of three files
> under net/, and as far as I can see, there's no reason for these three
> files to #include pci.h .
> net/ieee80211/ieee80211_module.c | 1 -
> net/ieee80211/ieee80211_rx.c | 1 -
> net/ieee80211/ieee80211_tx.c | 1 -
I don't know where these came from since Host AP driver does not include
linux/pci.h into the files doing generic IEEE 802.11 processing. Anyway,
I have nothing against removing these include lines.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [2.6 patch] drivers/net/wan/: possible cleanups
From: Adrian Bunk @ 2005-05-31 0:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, Linux Kernel Mailing List
This patch contains possible cleanups including the following:
- make needlessly global code static
- #if 0 the following unused global function:
- sdladrv.c: sdla_intde
- remove the following unused global variable:
- lmc_media.c: lmc_t1_cables
- remove the following unneeded EXPORT_SYMBOL's:
- cycx_drv.c: cycx_inten
- sdladrv.c: sdla_inten
- sdladrv.c: sdla_intde
- sdladrv.c: sdla_intack
- sdladrv.c: sdla_intr
- syncppp.c: sppp_input
- syncppp.c: sppp_change_mtu
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 18 Apr 2005
drivers/net/wan/cycx_drv.c | 7 +-
drivers/net/wan/cycx_main.c | 2
drivers/net/wan/dscc4.c | 14 ++---
drivers/net/wan/farsync.c | 24 ++++----
drivers/net/wan/hdlc_fr.c | 2
drivers/net/wan/lmc/lmc_debug.c | 10 +--
drivers/net/wan/lmc/lmc_media.c | 8 --
drivers/net/wan/pc300.h | 16 -----
drivers/net/wan/pc300_drv.c | 87 ++++++++++++++++----------------
drivers/net/wan/pc300_tty.c | 18 +++---
drivers/net/wan/sdla.c | 20 +++----
drivers/net/wan/sdladrv.c | 16 ++---
drivers/net/wan/syncppp.c | 10 +--
include/linux/cycx_drv.h | 1
include/linux/sdladrv.h | 4 -
include/net/syncppp.h | 1
16 files changed, 101 insertions(+), 139 deletions(-)
--- linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h.old 2005-02-16 19:14:39.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h 2005-02-16 19:14:46.000000000 +0100
@@ -60,6 +60,5 @@
extern int cycx_poke(struct cycx_hw *hw, u32 addr, void *buf, u32 len);
extern int cycx_exec(void __iomem *addr);
-extern void cycx_inten(struct cycx_hw *hw);
extern void cycx_intr(struct cycx_hw *hw);
#endif /* _CYCX_DRV_H */
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c.old 2005-02-16 19:14:55.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c 2005-02-16 19:15:35.000000000 +0100
@@ -110,7 +110,7 @@
* < 0 error.
* Context: process */
-int __init cycx_drv_init(void)
+static int __init cycx_drv_init(void)
{
printk(KERN_INFO "%s v%u.%u %s\n", fullname, MOD_VERSION, MOD_RELEASE,
copyright);
@@ -120,7 +120,7 @@
/* Module 'remove' entry point.
* o release all remaining system resources */
-void cycx_drv_cleanup(void)
+static void cycx_drv_cleanup(void)
{
}
@@ -185,8 +185,7 @@
}
/* Enable interrupt generation. */
-EXPORT_SYMBOL(cycx_inten);
-void cycx_inten(struct cycx_hw *hw)
+static void cycx_inten(struct cycx_hw *hw)
{
writeb(0, hw->dpmbase);
}
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c.old 2005-02-16 19:46:47.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c 2005-02-16 19:47:00.000000000 +0100
@@ -103,7 +103,7 @@
* < 0 error.
* Context: process
*/
-int __init cycx_init(void)
+static int __init cycx_init(void)
{
int cnt, err = -ENOMEM;
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c.old 2005-02-16 23:57:37.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c 2005-02-17 00:00:26.000000000 +0100
@@ -74,11 +74,11 @@
/*
* Modules parameters and associated varaibles
*/
-int fst_txq_low = FST_LOW_WATER_MARK;
-int fst_txq_high = FST_HIGH_WATER_MARK;
-int fst_max_reads = 7;
-int fst_excluded_cards = 0;
-int fst_excluded_list[FST_MAX_CARDS];
+static int fst_txq_low = FST_LOW_WATER_MARK;
+static int fst_txq_high = FST_HIGH_WATER_MARK;
+static int fst_max_reads = 7;
+static int fst_excluded_cards = 0;
+static int fst_excluded_list[FST_MAX_CARDS];
module_param(fst_txq_low, int, 0);
module_param(fst_txq_high, int, 0);
@@ -572,13 +572,13 @@
static void fst_process_tx_work_q(unsigned long work_q);
static void fst_process_int_work_q(unsigned long work_q);
-DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0);
-DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0);
+static DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0);
+static DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0);
-struct fst_card_info *fst_card_array[FST_MAX_CARDS];
-spinlock_t fst_work_q_lock;
-u64 fst_work_txq;
-u64 fst_work_intq;
+static struct fst_card_info *fst_card_array[FST_MAX_CARDS];
+static spinlock_t fst_work_q_lock;
+static u64 fst_work_txq;
+static u64 fst_work_intq;
static void
fst_q_work_item(u64 * queue, int card_index)
@@ -1498,7 +1498,7 @@
* The interrupt service routine
* Dev_id is our fst_card_info pointer
*/
-irqreturn_t
+static irqreturn_t
fst_intr(int irq, void *dev_id, struct pt_regs *regs)
{
struct fst_card_info *card;
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/hdlc_fr.c.old 2005-02-17 00:00:38.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/hdlc_fr.c 2005-02-17 00:00:46.000000000 +0100
@@ -347,7 +347,7 @@
-int pvc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
+static int pvc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
pvc_device *pvc = dev_to_pvc(dev);
fr_proto_pvc_info info;
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/lmc/lmc_media.c.old 2005-02-17 00:02:29.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/lmc/lmc_media.c 2005-02-17 00:02:47.000000000 +0100
@@ -48,14 +48,6 @@
*/
/*
- * For lack of a better place, put the SSI cable stuff here.
- */
-char *lmc_t1_cables[] = {
- "V.10/RS423", "EIA530A", "reserved", "X.21", "V.35",
- "EIA449/EIA530/V.36", "V.28/EIA232", "none", NULL
-};
-
-/*
* protocol independent method.
*/
static void lmc_set_protocol (lmc_softc_t * const, lmc_ctl_t *);
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300.h.old 2005-02-17 00:03:07.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300.h 2005-02-17 00:55:23.000000000 +0100
@@ -472,24 +472,8 @@
#ifdef __KERNEL__
/* Function Prototypes */
-int dma_buf_write(pc300_t *, int, ucchar *, int);
-int dma_buf_read(pc300_t *, int, struct sk_buff *);
void tx_dma_start(pc300_t *, int);
-void rx_dma_start(pc300_t *, int);
-void tx_dma_stop(pc300_t *, int);
-void rx_dma_stop(pc300_t *, int);
-int cpc_queue_xmit(struct sk_buff *, struct net_device *);
-void cpc_net_rx(struct net_device *);
-void cpc_sca_status(pc300_t *, int);
-int cpc_change_mtu(struct net_device *, int);
-int cpc_ioctl(struct net_device *, struct ifreq *, int);
-int ch_config(pc300dev_t *);
-int rx_config(pc300dev_t *);
-int tx_config(pc300dev_t *);
-void cpc_opench(pc300dev_t *);
-void cpc_closech(pc300dev_t *);
int cpc_open(struct net_device *dev);
-int cpc_close(struct net_device *dev);
int cpc_set_media(hdlc_device *, int);
#endif /* __KERNEL__ */
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300_drv.c.old 2005-02-17 00:03:20.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/pc300_drv.c 2005-02-17 00:14:10.000000000 +0100
@@ -291,6 +291,7 @@
static void plx_init(pc300_t *);
static void cpc_trace(struct net_device *, struct sk_buff *, char);
static int cpc_attach(struct net_device *, unsigned short, unsigned short);
+static int cpc_close(struct net_device *dev);
#ifdef CONFIG_PC300_MLPPP
void cpc_tty_init(pc300dev_t * dev);
@@ -437,7 +438,7 @@
printk("\n");
}
-int dma_get_rx_frame_size(pc300_t * card, int ch)
+static int dma_get_rx_frame_size(pc300_t * card, int ch)
{
volatile pcsca_bd_t __iomem *ptdescr;
ucshort first_bd = card->chan[ch].rx_first_bd;
@@ -462,7 +463,7 @@
* dma_buf_write: writes a frame to the Tx DMA buffers
* NOTE: this function writes one frame at a time.
*/
-int dma_buf_write(pc300_t * card, int ch, ucchar * ptdata, int len)
+static int dma_buf_write(pc300_t * card, int ch, ucchar * ptdata, int len)
{
int i, nchar;
volatile pcsca_bd_t __iomem *ptdescr;
@@ -503,7 +504,7 @@
* dma_buf_read: reads a frame from the Rx DMA buffers
* NOTE: this function reads one frame at a time.
*/
-int dma_buf_read(pc300_t * card, int ch, struct sk_buff *skb)
+static int dma_buf_read(pc300_t * card, int ch, struct sk_buff *skb)
{
int nchar;
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
@@ -560,7 +561,7 @@
return (rcvd);
}
-void tx_dma_stop(pc300_t * card, int ch)
+static void tx_dma_stop(pc300_t * card, int ch)
{
void __iomem *scabase = card->hw.scabase;
ucchar drr_ena_bit = 1 << (5 + 2 * ch);
@@ -571,7 +572,7 @@
cpc_writeb(scabase + DRR, drr_rst_bit & ~drr_ena_bit);
}
-void rx_dma_stop(pc300_t * card, int ch)
+static void rx_dma_stop(pc300_t * card, int ch)
{
void __iomem *scabase = card->hw.scabase;
ucchar drr_ena_bit = 1 << (4 + 2 * ch);
@@ -582,7 +583,7 @@
cpc_writeb(scabase + DRR, drr_rst_bit & ~drr_ena_bit);
}
-void rx_dma_start(pc300_t * card, int ch)
+static void rx_dma_start(pc300_t * card, int ch)
{
void __iomem *scabase = card->hw.scabase;
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
@@ -607,7 +608,7 @@
/*************************/
/*** FALC Routines ***/
/*************************/
-void falc_issue_cmd(pc300_t * card, int ch, ucchar cmd)
+static void falc_issue_cmd(pc300_t * card, int ch, ucchar cmd)
{
void __iomem *falcbase = card->hw.falcbase;
unsigned long i = 0;
@@ -622,7 +623,7 @@
cpc_writeb(falcbase + F_REG(CMDR, ch), cmd);
}
-void falc_intr_enable(pc300_t * card, int ch)
+static void falc_intr_enable(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -672,7 +673,7 @@
}
}
-void falc_open_timeslot(pc300_t * card, int ch, int timeslot)
+static void falc_open_timeslot(pc300_t * card, int ch, int timeslot)
{
void __iomem *falcbase = card->hw.falcbase;
ucchar tshf = card->chan[ch].falc.offset;
@@ -688,7 +689,7 @@
(0x80 >> (timeslot & 0x07)));
}
-void falc_close_timeslot(pc300_t * card, int ch, int timeslot)
+static void falc_close_timeslot(pc300_t * card, int ch, int timeslot)
{
void __iomem *falcbase = card->hw.falcbase;
ucchar tshf = card->chan[ch].falc.offset;
@@ -704,7 +705,7 @@
~(0x80 >> (timeslot & 0x07)));
}
-void falc_close_all_timeslots(pc300_t * card, int ch)
+static void falc_close_all_timeslots(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -726,7 +727,7 @@
}
}
-void falc_open_all_timeslots(pc300_t * card, int ch)
+static void falc_open_all_timeslots(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -758,7 +759,7 @@
}
}
-void falc_init_timeslot(pc300_t * card, int ch)
+static void falc_init_timeslot(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -776,7 +777,7 @@
}
}
-void falc_enable_comm(pc300_t * card, int ch)
+static void falc_enable_comm(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
falc_t *pfalc = (falc_t *) & chan->falc;
@@ -792,7 +793,7 @@
~((CPLD_REG1_FALC_DCD | CPLD_REG1_FALC_CTS) << (2 * ch)));
}
-void falc_disable_comm(pc300_t * card, int ch)
+static void falc_disable_comm(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
falc_t *pfalc = (falc_t *) & chan->falc;
@@ -806,7 +807,7 @@
((CPLD_REG1_FALC_DCD | CPLD_REG1_FALC_CTS) << (2 * ch)));
}
-void falc_init_t1(pc300_t * card, int ch)
+static void falc_init_t1(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -975,7 +976,7 @@
falc_close_all_timeslots(card, ch);
}
-void falc_init_e1(pc300_t * card, int ch)
+static void falc_init_e1(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1155,7 +1156,7 @@
falc_close_all_timeslots(card, ch);
}
-void falc_init_hdlc(pc300_t * card, int ch)
+static void falc_init_hdlc(pc300_t * card, int ch)
{
void __iomem *falcbase = card->hw.falcbase;
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
@@ -1181,7 +1182,7 @@
falc_intr_enable(card, ch);
}
-void te_config(pc300_t * card, int ch)
+static void te_config(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1241,7 +1242,7 @@
CPC_UNLOCK(card, flags);
}
-void falc_check_status(pc300_t * card, int ch, unsigned char frs0)
+static void falc_check_status(pc300_t * card, int ch, unsigned char frs0)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1397,7 +1398,7 @@
}
}
-void falc_update_stats(pc300_t * card, int ch)
+static void falc_update_stats(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1450,7 +1451,7 @@
* the synchronizer and then sent to the system interface.
*----------------------------------------------------------------------------
*/
-void falc_remote_loop(pc300_t * card, int ch, int loop_on)
+static void falc_remote_loop(pc300_t * card, int ch, int loop_on)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1495,7 +1496,7 @@
* coding must be identical.
*----------------------------------------------------------------------------
*/
-void falc_local_loop(pc300_t * card, int ch, int loop_on)
+static void falc_local_loop(pc300_t * card, int ch, int loop_on)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
falc_t *pfalc = (falc_t *) & chan->falc;
@@ -1522,7 +1523,7 @@
* looped. They are originated by the FALC-LH transmitter.
*----------------------------------------------------------------------------
*/
-void falc_payload_loop(pc300_t * card, int ch, int loop_on)
+static void falc_payload_loop(pc300_t * card, int ch, int loop_on)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1576,7 +1577,7 @@
* Description: Turns XLU bit off in the proper register
*----------------------------------------------------------------------------
*/
-void turn_off_xlu(pc300_t * card, int ch)
+static void turn_off_xlu(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1597,7 +1598,7 @@
* Description: Turns XLD bit off in the proper register
*----------------------------------------------------------------------------
*/
-void turn_off_xld(pc300_t * card, int ch)
+static void turn_off_xld(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1619,7 +1620,7 @@
* to generate a LOOP activation code over a T1/E1 line.
*----------------------------------------------------------------------------
*/
-void falc_generate_loop_up_code(pc300_t * card, int ch)
+static void falc_generate_loop_up_code(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1652,7 +1653,7 @@
* to generate a LOOP deactivation code over a T1/E1 line.
*----------------------------------------------------------------------------
*/
-void falc_generate_loop_down_code(pc300_t * card, int ch)
+static void falc_generate_loop_down_code(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1682,7 +1683,7 @@
* it on the reception side.
*----------------------------------------------------------------------------
*/
-void falc_pattern_test(pc300_t * card, int ch, unsigned int activate)
+static void falc_pattern_test(pc300_t * card, int ch, unsigned int activate)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -1729,7 +1730,7 @@
* Description: This routine returns the bit error counter value
*----------------------------------------------------------------------------
*/
-ucshort falc_pattern_test_error(pc300_t * card, int ch)
+static ucshort falc_pattern_test_error(pc300_t * card, int ch)
{
pc300ch_t *chan = (pc300ch_t *) & card->chan[ch];
falc_t *pfalc = (falc_t *) & chan->falc;
@@ -1769,7 +1770,7 @@
netif_rx(skb);
}
-void cpc_tx_timeout(struct net_device *dev)
+static void cpc_tx_timeout(struct net_device *dev)
{
pc300dev_t *d = (pc300dev_t *) dev->priv;
pc300ch_t *chan = (pc300ch_t *) d->chan;
@@ -1797,7 +1798,7 @@
netif_wake_queue(dev);
}
-int cpc_queue_xmit(struct sk_buff *skb, struct net_device *dev)
+static int cpc_queue_xmit(struct sk_buff *skb, struct net_device *dev)
{
pc300dev_t *d = (pc300dev_t *) dev->priv;
pc300ch_t *chan = (pc300ch_t *) d->chan;
@@ -1880,7 +1881,7 @@
return 0;
}
-void cpc_net_rx(struct net_device *dev)
+static void cpc_net_rx(struct net_device *dev)
{
pc300dev_t *d = (pc300dev_t *) dev->priv;
pc300ch_t *chan = (pc300ch_t *) d->chan;
@@ -2403,7 +2404,7 @@
return IRQ_HANDLED;
}
-void cpc_sca_status(pc300_t * card, int ch)
+static void cpc_sca_status(pc300_t * card, int ch)
{
ucchar ilar;
void __iomem *scabase = card->hw.scabase;
@@ -2495,7 +2496,7 @@
}
}
-void cpc_falc_status(pc300_t * card, int ch)
+static void cpc_falc_status(pc300_t * card, int ch)
{
pc300ch_t *chan = &card->chan[ch];
falc_t *pfalc = (falc_t *) & chan->falc;
@@ -2523,7 +2524,7 @@
CPC_UNLOCK(card, flags);
}
-int cpc_change_mtu(struct net_device *dev, int new_mtu)
+static int cpc_change_mtu(struct net_device *dev, int new_mtu)
{
if ((new_mtu < 128) || (new_mtu > PC300_DEF_MTU))
return -EINVAL;
@@ -2531,7 +2532,7 @@
return 0;
}
-int cpc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
+static int cpc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
hdlc_device *hdlc = dev_to_hdlc(dev);
pc300dev_t *d = (pc300dev_t *) dev->priv;
@@ -2856,7 +2857,7 @@
}
}
-int ch_config(pc300dev_t * d)
+static int ch_config(pc300dev_t * d)
{
pc300ch_t *chan = (pc300ch_t *) d->chan;
pc300chconf_t *conf = (pc300chconf_t *) & chan->conf;
@@ -3004,7 +3005,7 @@
return 0;
}
-int rx_config(pc300dev_t * d)
+static int rx_config(pc300dev_t * d)
{
pc300ch_t *chan = (pc300ch_t *) d->chan;
pc300_t *card = (pc300_t *) chan->card;
@@ -3035,7 +3036,7 @@
return 0;
}
-int tx_config(pc300dev_t * d)
+static int tx_config(pc300dev_t * d)
{
pc300ch_t *chan = (pc300ch_t *) d->chan;
pc300_t *card = (pc300_t *) chan->card;
@@ -3098,7 +3099,7 @@
return 0;
}
-void cpc_opench(pc300dev_t * d)
+static void cpc_opench(pc300dev_t * d)
{
pc300ch_t *chan = (pc300ch_t *) d->chan;
pc300_t *card = (pc300_t *) chan->card;
@@ -3116,7 +3117,7 @@
cpc_readb(scabase + M_REG(CTL, ch)) & ~(CTL_RTS | CTL_DTR));
}
-void cpc_closech(pc300dev_t * d)
+static void cpc_closech(pc300dev_t * d)
{
pc300ch_t *chan = (pc300ch_t *) d->chan;
pc300_t *card = (pc300_t *) chan->card;
@@ -3173,7 +3174,7 @@
return 0;
}
-int cpc_close(struct net_device *dev)
+static int cpc_close(struct net_device *dev)
{
hdlc_device *hdlc = dev_to_hdlc(dev);
pc300dev_t *d = (pc300dev_t *) dev->priv;
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdla.c.old 2005-02-17 00:15:50.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdla.c 2005-02-17 00:17:56.000000000 +0100
@@ -182,7 +182,7 @@
return(byte);
}
-void sdla_stop(struct net_device *dev)
+static void sdla_stop(struct net_device *dev)
{
struct frad_local *flp;
@@ -209,7 +209,7 @@
}
}
-void sdla_start(struct net_device *dev)
+static void sdla_start(struct net_device *dev)
{
struct frad_local *flp;
@@ -247,7 +247,7 @@
*
***************************************************/
-int sdla_z80_poll(struct net_device *dev, int z80_addr, int jiffs, char resp1, char resp2)
+static int sdla_z80_poll(struct net_device *dev, int z80_addr, int jiffs, char resp1, char resp2)
{
unsigned long start, done, now;
char resp, *temp;
@@ -505,7 +505,7 @@
static int sdla_reconfig(struct net_device *dev);
-int sdla_activate(struct net_device *slave, struct net_device *master)
+static int sdla_activate(struct net_device *slave, struct net_device *master)
{
struct frad_local *flp;
int i;
@@ -527,7 +527,7 @@
return(0);
}
-int sdla_deactivate(struct net_device *slave, struct net_device *master)
+static int sdla_deactivate(struct net_device *slave, struct net_device *master)
{
struct frad_local *flp;
int i;
@@ -549,7 +549,7 @@
return(0);
}
-int sdla_assoc(struct net_device *slave, struct net_device *master)
+static int sdla_assoc(struct net_device *slave, struct net_device *master)
{
struct frad_local *flp;
int i;
@@ -585,7 +585,7 @@
return(0);
}
-int sdla_deassoc(struct net_device *slave, struct net_device *master)
+static int sdla_deassoc(struct net_device *slave, struct net_device *master)
{
struct frad_local *flp;
int i;
@@ -613,7 +613,7 @@
return(0);
}
-int sdla_dlci_conf(struct net_device *slave, struct net_device *master, int get)
+static int sdla_dlci_conf(struct net_device *slave, struct net_device *master, int get)
{
struct frad_local *flp;
struct dlci_local *dlp;
@@ -1324,7 +1324,7 @@
return(0);
}
-int sdla_change_mtu(struct net_device *dev, int new_mtu)
+static int sdla_change_mtu(struct net_device *dev, int new_mtu)
{
struct frad_local *flp;
@@ -1337,7 +1337,7 @@
return(-EOPNOTSUPP);
}
-int sdla_set_config(struct net_device *dev, struct ifmap *map)
+static int sdla_set_config(struct net_device *dev, struct ifmap *map)
{
struct frad_local *flp;
int i;
--- linux-2.6.11-rc3-mm2-full/include/linux/sdladrv.h.old 2005-02-17 00:18:15.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/include/linux/sdladrv.h 2005-02-17 00:19:47.000000000 +0100
@@ -52,12 +52,8 @@
extern int sdla_setup (sdlahw_t* hw, void* sfm, unsigned len);
extern int sdla_down (sdlahw_t* hw);
-extern int sdla_inten (sdlahw_t* hw);
-extern int sdla_intde (sdlahw_t* hw);
-extern int sdla_intack (sdlahw_t* hw);
extern void S514_intack (sdlahw_t* hw, u32 int_status);
extern void read_S514_int_stat (sdlahw_t* hw, u32* int_status);
-extern int sdla_intr (sdlahw_t* hw);
extern int sdla_mapmem (sdlahw_t* hw, unsigned long addr);
extern int sdla_peek (sdlahw_t* hw, unsigned long addr, void* buf,
unsigned len);
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdladrv.c.old 2005-02-17 00:18:30.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/sdladrv.c 2005-02-17 00:20:04.000000000 +0100
@@ -642,9 +642,7 @@
* Enable interrupt generation.
*/
-EXPORT_SYMBOL(sdla_inten);
-
-int sdla_inten (sdlahw_t* hw)
+static int sdla_inten (sdlahw_t* hw)
{
unsigned port = hw->port;
int tmp, i;
@@ -698,8 +696,7 @@
* Disable interrupt generation.
*/
-EXPORT_SYMBOL(sdla_intde);
-
+#if 0
int sdla_intde (sdlahw_t* hw)
{
unsigned port = hw->port;
@@ -748,14 +745,13 @@
}
return 0;
}
+#endif /* 0 */
/*============================================================================
* Acknowledge SDLA hardware interrupt.
*/
-EXPORT_SYMBOL(sdla_intack);
-
-int sdla_intack (sdlahw_t* hw)
+static int sdla_intack (sdlahw_t* hw)
{
unsigned port = hw->port;
int tmp;
@@ -827,8 +823,7 @@
* Generate an interrupt to adapter's CPU.
*/
-EXPORT_SYMBOL(sdla_intr);
-
+#if 0
int sdla_intr (sdlahw_t* hw)
{
unsigned port = hw->port;
@@ -863,6 +858,7 @@
}
return 0;
}
+#endif /* 0 */
/*============================================================================
* Execute Adapter Command.
--- linux-2.6.11-rc3-mm2-full/include/net/syncppp.h.old 2005-02-17 00:20:19.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/include/net/syncppp.h 2005-02-17 00:20:25.000000000 +0100
@@ -86,7 +86,6 @@
void sppp_attach (struct ppp_device *pd);
void sppp_detach (struct net_device *dev);
-void sppp_input (struct net_device *dev, struct sk_buff *m);
int sppp_do_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd);
struct sk_buff *sppp_dequeue (struct net_device *dev);
int sppp_isempty (struct net_device *dev);
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/syncppp.c.old 2005-02-17 00:20:36.000000000 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/syncppp.c 2005-02-17 00:21:37.000000000 +0100
@@ -221,7 +221,7 @@
* here.
*/
-void sppp_input (struct net_device *dev, struct sk_buff *skb)
+static void sppp_input (struct net_device *dev, struct sk_buff *skb)
{
struct ppp_header *h;
struct sppp *sp = (struct sppp *)sppp_of(dev);
@@ -355,8 +355,6 @@
return;
}
-EXPORT_SYMBOL(sppp_input);
-
/*
* Handle transmit packets.
*/
@@ -990,7 +988,7 @@
* the mtu is out of range.
*/
-int sppp_change_mtu(struct net_device *dev, int new_mtu)
+static int sppp_change_mtu(struct net_device *dev, int new_mtu)
{
if(new_mtu<128||new_mtu>PPP_MTU||(dev->flags&IFF_UP))
return -EINVAL;
@@ -998,8 +996,6 @@
return 0;
}
-EXPORT_SYMBOL(sppp_change_mtu);
-
/**
* sppp_do_ioctl - Ioctl handler for ppp/hdlc
* @dev: Device subject to ioctl
@@ -1455,7 +1451,7 @@
return 0;
}
-struct packet_type sppp_packet_type = {
+static struct packet_type sppp_packet_type = {
.type = __constant_htons(ETH_P_WAN_PPP),
.func = sppp_rcv,
};
--- linux-2.6.12-rc2-mm3-full/drivers/net/wan/lmc/lmc_debug.c.old 2005-04-18 22:42:50.000000000 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/lmc/lmc_debug.c 2005-04-18 22:44:32.000000000 +0200
@@ -8,10 +8,10 @@
/*
* Prints out len, max to 80 octets using printk, 20 per line
*/
-void lmcConsoleLog(char *type, unsigned char *ucData, int iLen)
-{
#ifdef DEBUG
#ifdef LMC_PACKET_LOG
+void lmcConsoleLog(char *type, unsigned char *ucData, int iLen)
+{
int iNewLine = 1;
char str[80], *pstr;
@@ -43,26 +43,24 @@
}
sprintf(pstr, "\n");
printk(str);
+}
#endif
#endif
-}
#ifdef DEBUG
u_int32_t lmcEventLogIndex = 0;
u_int32_t lmcEventLogBuf[LMC_EVENTLOGSIZE * LMC_EVENTLOGARGS];
-#endif
void lmcEventLog (u_int32_t EventNum, u_int32_t arg2, u_int32_t arg3)
{
-#ifdef DEBUG
lmcEventLogBuf[lmcEventLogIndex++] = EventNum;
lmcEventLogBuf[lmcEventLogIndex++] = arg2;
lmcEventLogBuf[lmcEventLogIndex++] = arg3;
lmcEventLogBuf[lmcEventLogIndex++] = jiffies;
lmcEventLogIndex &= (LMC_EVENTLOGSIZE * LMC_EVENTLOGARGS) - 1;
-#endif
}
+#endif /* DEBUG */
void lmc_trace(struct net_device *dev, char *msg){
#ifdef LMC_TRACE
--- linux-2.6.12-rc2-mm3-full/drivers/net/wan/pc300_tty.c.old 2005-04-18 22:45:21.000000000 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/pc300_tty.c 2005-04-18 22:46:51.000000000 +0200
@@ -112,10 +112,10 @@
static struct tty_driver serial_drv;
/* local variables */
-st_cpc_tty_area cpc_tty_area[CPC_TTY_NPORTS];
+static st_cpc_tty_area cpc_tty_area[CPC_TTY_NPORTS];
-int cpc_tty_cnt=0; /* number of intrfaces configured with MLPPP */
-int cpc_tty_unreg_flag = 0;
+static int cpc_tty_cnt = 0; /* number of intrfaces configured with MLPPP */
+static int cpc_tty_unreg_flag = 0;
/* TTY functions prototype */
static int cpc_tty_open(struct tty_struct *tty, struct file *flip);
@@ -132,9 +132,9 @@
static void cpc_tty_signal_off(pc300dev_t *pc300dev, unsigned char);
static void cpc_tty_signal_on(pc300dev_t *pc300dev, unsigned char);
-int pc300_tiocmset(struct tty_struct *, struct file *,
- unsigned int, unsigned int);
-int pc300_tiocmget(struct tty_struct *, struct file *);
+static int pc300_tiocmset(struct tty_struct *, struct file *,
+ unsigned int, unsigned int);
+static int pc300_tiocmget(struct tty_struct *, struct file *);
/* functions called by PC300 driver */
void cpc_tty_init(pc300dev_t *dev);
@@ -540,8 +540,8 @@
return(0);
}
-int pc300_tiocmset(struct tty_struct *tty, struct file *file,
- unsigned int set, unsigned int clear)
+static int pc300_tiocmset(struct tty_struct *tty, struct file *file,
+ unsigned int set, unsigned int clear)
{
st_cpc_tty_area *cpc_tty;
@@ -567,7 +567,7 @@
return 0;
}
-int pc300_tiocmget(struct tty_struct *tty, struct file *file)
+static int pc300_tiocmget(struct tty_struct *tty, struct file *file)
{
unsigned int result;
unsigned char status;
--- linux-2.6.12-rc2-mm3-full/drivers/net/wan/dscc4.c.old 2005-04-18 23:16:49.000000000 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/wan/dscc4.c 2005-04-18 23:18:21.000000000 +0200
@@ -446,8 +446,8 @@
return readl(dpriv->base_addr + CH0FTDA + dpriv->dev_id*4) == dpriv->ltda;
}
-int state_check(u32 state, struct dscc4_dev_priv *dpriv, struct net_device *dev,
- const char *msg)
+static int state_check(u32 state, struct dscc4_dev_priv *dpriv,
+ struct net_device *dev, const char *msg)
{
int ret = 0;
@@ -466,8 +466,9 @@
return ret;
}
-void dscc4_tx_print(struct net_device *dev, struct dscc4_dev_priv *dpriv,
- char *msg)
+static void dscc4_tx_print(struct net_device *dev,
+ struct dscc4_dev_priv *dpriv,
+ char *msg)
{
printk(KERN_DEBUG "%s: tx_current=%02d tx_dirty=%02d (%s)\n",
dev->name, dpriv->tx_current, dpriv->tx_dirty, msg);
@@ -507,7 +508,8 @@
}
}
-inline int try_get_rx_skb(struct dscc4_dev_priv *dpriv, struct net_device *dev)
+static inline int try_get_rx_skb(struct dscc4_dev_priv *dpriv,
+ struct net_device *dev)
{
unsigned int dirty = dpriv->rx_dirty%RX_RING_SIZE;
struct RxFD *rx_fd = dpriv->rx_fd + dirty;
@@ -1894,7 +1896,7 @@
* It failed and locked solid. Thus the introduction of a dummy skb.
* Problem is acknowledged in errata sheet DS5. Joy :o/
*/
-struct sk_buff *dscc4_init_dummy_skb(struct dscc4_dev_priv *dpriv)
+static struct sk_buff *dscc4_init_dummy_skb(struct dscc4_dev_priv *dpriv)
{
struct sk_buff *skb;
^ permalink raw reply
* [-mm patch] fix IEEE80211_CRYPT_* selects
From: Adrian Bunk @ 2005-05-31 0:33 UTC (permalink / raw)
To: Andrew Morton, netdev, jgarzik; +Cc: linux-kernel
Some of the options didn't obey the most important rule of select
If you select something, you have to ensure that the dependencies
of what you do select are fulfilled.
resulting in the following compile error:
<-- snip -->
...
LD .tmp_vmlinux1
crypto/built-in.o(.init.text+0x31b): In function `aes_init':
: undefined reference to `crypto_register_alg'
crypto/built-in.o(.init.text+0x326): In function `michael_mic_init':
: undefined reference to `crypto_register_alg'
crypto/built-in.o(.exit.text+0x6): In function `aes_fini':
: undefined reference to `crypto_unregister_alg'
crypto/built-in.o(.exit.text+0x16): In function `michael_mic_exit':
: undefined reference to `crypto_unregister_alg'
net/built-in.o(.text+0x5ba52): In function `ieee80211_ccmp_init':
: undefined reference to `crypto_alloc_tfm'
net/built-in.o(.text+0x5ba94): In function `ieee80211_ccmp_init':
: undefined reference to `crypto_free_tfm'
net/built-in.o(.text+0x5bab7): In function `ieee80211_ccmp_deinit':
: undefined reference to `crypto_free_tfm'
net/built-in.o(.text+0x5c5c2): In function `ieee80211_tkip_init':
: undefined reference to `crypto_alloc_tfm'
net/built-in.o(.text+0x5c5d5): In function `ieee80211_tkip_init':
: undefined reference to `crypto_alloc_tfm'
net/built-in.o(.text+0x5c623): In function `ieee80211_tkip_init':
: undefined reference to `crypto_free_tfm'
net/built-in.o(.text+0x5c62a): In function `ieee80211_tkip_init':
: undefined reference to `crypto_free_tfm'
net/built-in.o(.text+0x5c65e): In function `ieee80211_tkip_deinit':
: undefined reference to `crypto_free_tfm'
net/built-in.o(.text+0x5c665): In function `ieee80211_tkip_deinit':
: undefined reference to `crypto_free_tfm'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
This patch adds the missing selects of CRYPTO (similar to how
IEEE80211_CRYPT_WEP already does it).
Yes, you could argue whether CRYPTO should be select'ed by the CRYPTO_*
options, but with the current CRYPTO* dependencies this patch is
required.
---
This patch was already sent on:
- 7 May 2005
- 26 Feb 2005
net/ieee80211/Kconfig | 2 ++
1 files changed, 2 insertions(+)
--- linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig.old 2005-02-26 12:12:44.000000000 +0100
+++ linux-2.6.11-rc4-mm1-full/net/ieee80211/Kconfig 2005-02-26 12:13:47.000000000 +0100
@@ -42,10 +42,11 @@
"ieee80211_crypt_wep".
config IEEE80211_CRYPT_CCMP
tristate "IEEE 802.11i CCMP support"
depends on IEEE80211
+ select CRYPTO
select CRYPTO_AES
---help---
Include software based cipher suites in support of IEEE 802.11i
(aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled
networks.
@@ -54,10 +55,11 @@
"ieee80211_crypt_ccmp".
config IEEE80211_CRYPT_TKIP
tristate "IEEE 802.11i TKIP encryption"
depends on IEEE80211
+ select CRYPTO
select CRYPTO_MICHAEL_MIC
---help---
Include software based cipher suites in support of IEEE 802.11i
(aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with TKIP enabled
networks.
^ permalink raw reply
* [TC PATCH] some fixes for ipt action
From: Pablo Neira @ 2005-05-31 0:28 UTC (permalink / raw)
To: shemminger; +Cc: jamal, netdev
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
Hi Stephen,
I've sent this patch to jamal some weeks ago. He's acked it, you can
confirm that from him. This patch:
- fixes a leak on error paths (a similar path was commited to iptables
two days ago[1]).
- simplify option handling.
- fixes final_check checking, it was broken.
[1]
https://lists.netfilter.org/pipermail/netfilter-devel/2005-May/019844.html
Pablo
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 2802 bytes --]
===== tc/m_ipt.c 1.5 vs edited =====
--- 1.5/tc/m_ipt.c 2005-03-24 12:53:31 +01:00
+++ edited/tc/m_ipt.c 2005-03-31 02:05:42 +02:00
@@ -69,6 +69,7 @@
};
static struct iptables_target *t_list = NULL;
+static struct option *opts = original_opts;
static unsigned int global_option_offset = 0;
#define OPTION_OFFSET 256
@@ -169,18 +170,13 @@
return result;
}
-static struct option *
-copy_options(struct option *oldopts)
+static void free_opts(struct option *opts)
{
- struct option *merge;
- unsigned int num_old;
- for (num_old = 0; oldopts[num_old].name; num_old++) ;
- merge = malloc(sizeof (struct option) * (num_old + 1));
- if (NULL == merge)
- return NULL;
- memcpy(merge, oldopts, num_old * sizeof (struct option));
- memset(merge + num_old, 0, sizeof (struct option));
- return merge;
+ if (opts != original_opts) {
+ free(opts);
+ opts = original_opts;
+ global_option_offset = 0;
+ }
}
static struct option *
@@ -385,7 +381,6 @@
int c;
int rargc = *argc_p;
char **argv = *argv_p;
- struct option *opts;
int argc = 0, iargc = 0;
char k[16];
int res = -1;
@@ -409,11 +404,6 @@
return -1;
}
- opts = copy_options(original_opts);
-
- if (NULL == opts)
- return -1;
-
while (1) {
c = getopt_long(argc, argv, "j:", opts, NULL);
if (c == -1)
@@ -440,23 +430,14 @@
default:
memset(&fw, 0, sizeof (fw));
if (m) {
- unsigned int fake_flags = 0;
m->parse(c - m->option_offset, argv, 0,
- &fake_flags, NULL, &m->t);
+ &m->tflags, NULL, &m->t);
} else {
fprintf(stderr," failed to find target %s\n\n", optarg);
return -1;
}
ok++;
-
- /*m->final_check(m->t); -- Is this necessary?
- ** useful when theres depencies
- ** eg ipt_TCPMSS.c has have the TCP match loaded
- ** before this can be used;
- ** also seems the ECN target needs it
- */
-
break;
}
@@ -466,6 +447,7 @@
if (matches(argv[optind], "index") == 0) {
if (get_u32(&index, argv[optind + 1], 10)) {
fprintf(stderr, "Illegal \"index\"\n");
+ free_opts(opts);
return -1;
}
iok++;
@@ -479,6 +461,10 @@
return -1;
}
+ /* check that we passed the correct parameters to the target */
+ if (m)
+ m->final_check(m->tflags);
+
{
struct tcmsg *t = NLMSG_DATA(n);
if (t->tcm_parent != TC_H_ROOT
@@ -519,6 +505,7 @@
*argv_p = argv;
optind = 1;
+ free_opts(opts);
return 0;
@@ -529,16 +516,10 @@
{
struct rtattr *tb[TCA_IPT_MAX + 1];
struct ipt_entry_target *t = NULL;
- struct option *opts;
if (arg == NULL)
return -1;
- opts = copy_options(original_opts);
-
- if (NULL == opts)
- return -1;
-
parse_rtattr_nested(tb, TCA_IPT_MAX, arg);
if (tb[TCA_IPT_TABLE] == NULL) {
@@ -601,6 +582,7 @@
fprintf(f, " \n");
}
+ free_opts(opts);
return 0;
}
^ permalink raw reply
* Re: r8169 802.1q/MTU bug
From: James Harr @ 2005-05-31 0:27 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20050530071148.GB1514@electric-eye.fr.zoreil.com>
Hi,
The driver you sent gives me an error when I try to compile and load it with
2.6.11.11:
# make
[...]
CC [M] drivers/net/r8169.o
drivers/net/r8169.c: In function `rtl8169_down':
drivers/net/r8169.c:2589: warning: implicit declaration of function
synchronize_sched
[...]
# insmod drivers/net/r8169.ko
insmod: error inserting 'drivers/net/r8169.ko': -1 Unknown symbol in module
It does a similar thing when I try to install it:
# make modules_install
[...]
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.11.11; fi
WARNING: /lib/modules/2.6.11.11/kernel/drivers/net/r8169.ko needs unknown
symbol synchronize_sched
As I noted in a previous email, it doesn't give me this problem when I have
jumbo frames enabled on my switch.
Since I found out my switch supported jumbo frames, I started to toy around
with larger MTUs. When a VLAN's MTU was set to 7200, my system locked up. I
didn't have this problem at 7196. Also, the crash problem wasn't there on a
regular interface with no VLANs and the MTU at 7200.
Thanks,
James Harr
On Monday 30 May 2005 2:11 am, you wrote:
> James Harr <james@grickle.org> :
> [...]
>
> > I've been using a gigabit RealTek 8169 card for a while, I just recently
> > started using 802.1q with them. I stumbled upon the problem described at
> > the top of here:
> >
> > http://www.candelatech.com/~greear/vlan/howto.html
>
> Can you try the attached version of the r8169 driver with the latest
> kernel ?
>
> If the issue is still there, it is almost surely the one you link to.
> I'll give it a look when I'm back at home, it should not be long to fix.
>
> Please Cc: netdev@oss.sgi.com (it is archived and googlable).
--
James Harr <james@grickle.org>
http://www.grickle.org/
^ permalink raw reply
* Re: [PATCH 1/2] Resend: LSM-IPSec Networking Hooks
From: James Morris @ 2005-05-31 0:02 UTC (permalink / raw)
To: jaegert; +Cc: netdev, chrisw, serue, latten, sds
In-Reply-To: <1116361510.5560.121.camel@dyn9002018177.watson.ibm.com>
On Tue, 17 May 2005, jaegert wrote:
> The pfkey interface is tested using the ipsec-tools. ipsec-tools have
> been modified (a separate ipsec-tools patch is available for version
> 0.5) that supports assignment of xfrm_policy entries and security
> associations with security contexts via setkey and the negotiation
> using the security contexts via racoon.
>
> The xfrm_user interface is tested via ad hoc programs that set
> security contexts. These programs are also available from me, and
> contain programs for setting, getting, and deleting policy for testing
> this interface. Testing of sa functions was done by tracing kernel
> behavior.
Can you please publish or send me (so I can publish) the ipsec-tools patch
and these xfrm_user utilities?
> [SADB_X_EXT_NAT_T_OA] = (u8) sizeof(struct sadb_address),
> + [SADB_X_EXT_SEC_CTX] = (u8) sizeof(struct sadb_x_sec_ctx),
> };
Indenting.
> if (km_query(x, tmpl, pol) == 0) {
> + if (!xfrm_sec_ctx_match(xfrm_policy_security(pol), xfrm_state_security(x))) {
> + x->km.state = XFRM_STATE_DEAD;
> + xfrm_state_put(x);
> + x = NULL;
> + error = 1;
> + goto out;
> + }
Why set error to 1 here? This should be an -E value.
> + if (security_xfrm_policy_clone(old, newp)) {
> + kfree(newp);
> + return (struct xfrm_policy *)NULL; /* ENOMEM */
> + }
Don't cast NULL.
> +static inline int xfrm_user_sec_ctx_size(struct xfrm_policy *xp)
> +{
> + struct xfrm_sec_ctx *xfrm_ctx = xfrm_policy_security(xp);
> + int len;
> +
> + if (xfrm_ctx) {
> + len = sizeof(struct xfrm_user_sec_ctx);
> + len += xfrm_ctx->ctx_len;
> + return len;
> + }
> + return 0;
> +}
This can be simplified with a single return path, initialize len to zero.
> +static int attach_sec_ctx(struct xfrm_state *x, struct rtattr *u_arg)
> +{
> + struct xfrm_user_sec_ctx *uxsc = RTA_DATA(u_arg);
> +
> + if (uxsc) {
> + security_xfrm_state_free(x);
> + return security_xfrm_state_alloc(x, uxsc);
> + }
> +
> + return 0;
> +}
The security_xfrm_state_free() seems unecesary and buggy if needed. This
is called in state allocation context, i.e. just afer xfrm_state_alloc()
and there should be no already allocate security state.
> +static int copy_sec_ctx(struct xfrm_policy *pol, struct xfrm_user_sec_ctx *uctx)
> +{
> + int err = 0;
> +
> + security_xfrm_policy_free(pol);
> + err = security_xfrm_policy_alloc(pol, uctx);
> + return err;
> +}
Again, why free just before allocation? This code is only being called in
policy allocation context and freeing like this would be buggy in any
case.
> +static int copy_from_user_sec_ctx(struct xfrm_policy *pol, struct rtattr **xfrma)
> +{
> + struct rtattr *rt = xfrma[XFRMA_SEC_CTX-1];
> + struct xfrm_user_sec_ctx *uctx = RTA_DATA(rt);
> +
> + if (uctx) {
> + copy_sec_ctx(pol, uctx);
> + }
> +
> + return 0;
> +}
If it always returns zero, make it a void function.
> + /* spi must be zero'd unless real tmpl */
> + for (tmpl = ut; tmpl->id.spi != 0; tmpl = tmpl + 1)
Indenting.
> + else {
> + uctx = (struct xfrm_user_sec_ctx *) NULL;
> nr = ((len - sizeof(*p)) / sizeof(*ut));
> if (nr > XFRM_MAX_DEPTH)
> return NULL;
> + }
Indenting.
> + if (uctx)
> + copy_sec_ctx(xp, uctx);
Why not just make copy_sec_ctx() check for uctx itself, so the calling
code can be cleaner?
> len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp->xfrm_nr);
> len += NLMSG_SPACE(sizeof(struct xfrm_user_polexpire));
> + len += xfrm_user_sec_ctx_size(xp);
> skb = alloc_skb(len, GFP_ATOMIC);
This looks wrong, the length is not aligned properly. NLMSG_SPACE needs
to enclose the xfrm_user_sec_ctx_size() as well. (There's another one of
these further down).
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply
* Re: Bug in 2.6.11.11 - udp_poll(), fragments + CONFIG_HIGHMEM
From: David S. Miller @ 2005-05-30 22:50 UTC (permalink / raw)
To: herbert; +Cc: Steven.Hand, linux-net, linux-kernel, netdev
In-Reply-To: <E1Dcs8Y-0006bl-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 31 May 2005 07:49:30 +1000
> Thanks for catching this. The receive queue lock is never taken
> in IRQs (and should never be) so we can simply substitute bh for
> irq.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 2.6] fix deadlock with ip_queue and tcp local input path
From: David S. Miller @ 2005-05-30 22:26 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20050530180654.GX22760@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Mon, 30 May 2005 20:06:54 +0200
> I've now tested the suggested solution by Patrick McHardy and Herbert Xu to
> simply use local_bh_{en,dis}able().
>
> Please apply the following patch to mainline.
Will do.
> btw: How do we get this into 2.6.11.x ?
You submit your patch to stable@kernel.org.
But I will take care of this for you Harald, don't
worry about it.
^ permalink raw reply
* Re: Bug in 2.6.11.11 - udp_poll(), fragments + CONFIG_HIGHMEM
From: Herbert Xu @ 2005-05-30 21:49 UTC (permalink / raw)
To: Steven Hand; +Cc: linux-net, linux-kernel, davem, Steven.Hand, netdev
In-Reply-To: <E1DclTK-0002qE-00@mta1.cl.cam.ac.uk>
Steven Hand <Steven.Hand@cl.cam.ac.uk> wrote:
>
> Reconstructed forward trace:
>
> net/ipv4/udp.c:1334 spin_lock_irq()
> net/ipv4/udp.c:1336 udp_checksum_complete()
> net/core/skbuff.c:1069 skb_shinfo(skb)->nr_frags > 1
> net/core/skbuff.c:1086 kunmap_skb_frag()
> net/core/skbuff.h:1087 local_bh_enable()
> kernel/softirq.c:0140 WARN_ON(irqs_disabled());
Thanks for catching this. The receive queue lock is never taken
in IRQs (and should never be) so we can simply substitute bh for
irq.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -738,7 +738,7 @@ int udp_ioctl(struct sock *sk, int cmd,
unsigned long amount;
amount = 0;
- spin_lock_irq(&sk->sk_receive_queue.lock);
+ spin_lock_bh(&sk->sk_receive_queue.lock);
skb = skb_peek(&sk->sk_receive_queue);
if (skb != NULL) {
/*
@@ -748,7 +748,7 @@ int udp_ioctl(struct sock *sk, int cmd,
*/
amount = skb->len - sizeof(struct udphdr);
}
- spin_unlock_irq(&sk->sk_receive_queue.lock);
+ spin_unlock_bh(&sk->sk_receive_queue.lock);
return put_user(amount, (int __user *)arg);
}
@@ -848,12 +848,12 @@ csum_copy_err:
/* Clear queue. */
if (flags&MSG_PEEK) {
int clear = 0;
- spin_lock_irq(&sk->sk_receive_queue.lock);
+ spin_lock_bh(&sk->sk_receive_queue.lock);
if (skb == skb_peek(&sk->sk_receive_queue)) {
__skb_unlink(skb, &sk->sk_receive_queue);
clear = 1;
}
- spin_unlock_irq(&sk->sk_receive_queue.lock);
+ spin_unlock_bh(&sk->sk_receive_queue.lock);
if (clear)
kfree_skb(skb);
}
@@ -1334,7 +1334,7 @@ unsigned int udp_poll(struct file *file,
struct sk_buff_head *rcvq = &sk->sk_receive_queue;
struct sk_buff *skb;
- spin_lock_irq(&rcvq->lock);
+ spin_lock_bh(&rcvq->lock);
while ((skb = skb_peek(rcvq)) != NULL) {
if (udp_checksum_complete(skb)) {
UDP_INC_STATS_BH(UDP_MIB_INERRORS);
@@ -1345,7 +1345,7 @@ unsigned int udp_poll(struct file *file,
break;
}
}
- spin_unlock_irq(&rcvq->lock);
+ spin_unlock_bh(&rcvq->lock);
/* nothing to see, move along */
if (skb == NULL)
^ permalink raw reply
* [2.6 patch] net/ipv6/ipv6_syms.c: unexport fl6_sock_lookup
From: Adrian Bunk @ 2005-05-30 20:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, linux-kernel, Hideaki YOSHIFUJI
There is no usage of this EXPORT_SYMBOL in the kernel.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
---
This patch was already sent on:
- 7 May 2005
--- linux-2.6.12-rc3-mm3-full/net/ipv6/ipv6_syms.c.old 2005-05-05 22:23:17.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv6/ipv6_syms.c 2005-05-05 22:23:23.000000000 +0200
@@ -37,5 +37,4 @@
EXPORT_SYMBOL(xfrm6_rcv);
#endif
EXPORT_SYMBOL(rt6_lookup);
-EXPORT_SYMBOL(fl6_sock_lookup);
EXPORT_SYMBOL(ipv6_push_nfrag_opts);
^ permalink raw reply
* [RFC: 2.6 patch] net/ipv4/: possible cleanups
From: Adrian Bunk @ 2005-05-30 20:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, linux-kernel
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global function:
- xfrm4_state.c: xfrm4_state_fini
- remove the following unneeded EXPORT_SYMBOL's:
- ip_output.c: ip_finish_output
- ip_output.c: sysctl_ip_default_ttl
- fib_frontend.c: ip_dev_find
- inetpeer.c: inet_peer_idlock
- ip_options.c: ip_options_compile
- ip_options.c: ip_options_undo
- tcp_ipv4.c: sysctl_max_syn_backlog
Please review which of these changes are correct and which might
conflict with pending patches.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 7 May 2005
include/net/ip.h | 2 --
include/net/route.h | 4 ----
include/net/tcp.h | 2 --
include/net/tcp_ecn.h | 13 -------------
include/net/xfrm.h | 1 -
net/ipv4/fib_frontend.c | 1 -
net/ipv4/inetpeer.c | 2 --
net/ipv4/ip_options.c | 3 ---
net/ipv4/ip_output.c | 7 +------
net/ipv4/multipath_drr.c | 2 +-
net/ipv4/route.c | 4 +++-
net/ipv4/tcp_input.c | 15 ++++++++++++++-
net/ipv4/tcp_ipv4.c | 1 -
net/ipv4/xfrm4_state.c | 2 ++
14 files changed, 21 insertions(+), 38 deletions(-)
--- linux-2.6.12-rc3-mm2-full/include/net/ip.h.old 2005-05-05 02:35:00.000000000 +0200
+++ linux-2.6.12-rc3-mm2-full/include/net/ip.h 2005-05-05 02:35:07.000000000 +0200
@@ -140,8 +140,6 @@
void ip_send_reply(struct sock *sk, struct sk_buff *skb, struct ip_reply_arg *arg,
unsigned int len);
-extern int ip_finish_output(struct sk_buff *skb);
-
struct ipv4_config
{
int log_martians;
--- linux-2.6.12-rc3-mm2-full/net/ipv4/multipath_drr.c.old 2005-05-05 02:37:58.000000000 +0200
+++ linux-2.6.12-rc3-mm2-full/net/ipv4/multipath_drr.c 2005-05-05 02:38:06.000000000 +0200
@@ -107,7 +107,7 @@
return NOTIFY_DONE;
}
-struct notifier_block drr_dev_notifier = {
+static struct notifier_block drr_dev_notifier = {
.notifier_call = drr_dev_event,
};
--- linux-2.6.12-rc3-mm3-full/net/ipv4/ip_output.c.old 2005-05-05 21:43:22.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/ip_output.c 2005-05-05 21:44:36.000000000 +0200
@@ -216,7 +216,7 @@
return -EINVAL;
}
-int ip_finish_output(struct sk_buff *skb)
+static int ip_finish_output(struct sk_buff *skb)
{
struct net_device *dev = skb->dst->dev;
@@ -1351,12 +1351,7 @@
#endif
}
-EXPORT_SYMBOL(ip_finish_output);
EXPORT_SYMBOL(ip_fragment);
EXPORT_SYMBOL(ip_generic_getfrag);
EXPORT_SYMBOL(ip_queue_xmit);
EXPORT_SYMBOL(ip_send_check);
-
-#ifdef CONFIG_SYSCTL
-EXPORT_SYMBOL(sysctl_ip_default_ttl);
-#endif
--- linux-2.6.12-rc3-mm3-full/include/net/route.h.old 2005-05-05 21:21:09.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/include/net/route.h 2005-05-05 21:22:19.000000000 +0200
@@ -105,10 +105,6 @@
unsigned int out_hlist_search;
};
-extern struct rt_cache_stat *rt_cache_stat;
-#define RT_CACHE_STAT_INC(field) \
- (per_cpu_ptr(rt_cache_stat, _smp_processor_id())->field++)
-
extern struct ip_rt_acct *ip_rt_acct;
struct in_device;
--- linux-2.6.12-rc3-mm3-full/net/ipv4/route.c.old 2005-05-05 21:21:21.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/route.c 2005-05-05 21:22:14.000000000 +0200
@@ -209,7 +209,9 @@
static int rt_hash_log;
static unsigned int rt_hash_rnd;
-struct rt_cache_stat *rt_cache_stat;
+static struct rt_cache_stat *rt_cache_stat;
+#define RT_CACHE_STAT_INC(field) \
+ (per_cpu_ptr(rt_cache_stat, _smp_processor_id())->field++)
static int rt_intern_hash(unsigned hash, struct rtable *rth,
struct rtable **res);
--- linux-2.6.12-rc3-mm3-full/include/net/tcp.h.old 2005-05-05 21:23:42.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/include/net/tcp.h 2005-05-05 21:23:52.000000000 +0200
@@ -825,8 +825,6 @@
}
}
-extern void tcp_enter_quickack_mode(struct tcp_sock *tp);
-
static __inline__ void tcp_delack_init(struct tcp_sock *tp)
{
memset(&tp->ack, 0, sizeof(tp->ack));
--- linux-2.6.12-rc3-mm3-full/include/net/tcp_ecn.h.old 2005-05-05 21:25:48.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/include/net/tcp_ecn.h 2005-05-05 21:25:57.000000000 +0200
@@ -78,19 +78,6 @@
tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR;
}
-static inline void TCP_ECN_check_ce(struct tcp_sock *tp, struct sk_buff *skb)
-{
- if (tp->ecn_flags&TCP_ECN_OK) {
- if (INET_ECN_is_ce(TCP_SKB_CB(skb)->flags))
- tp->ecn_flags |= TCP_ECN_DEMAND_CWR;
- /* Funny extension: if ECT is not set on a segment,
- * it is surely retransmit. It is not in ECN RFC,
- * but Linux follows this rule. */
- else if (INET_ECN_is_not_ect((TCP_SKB_CB(skb)->flags)))
- tcp_enter_quickack_mode(tp);
- }
-}
-
static inline void TCP_ECN_rcv_synack(struct tcp_sock *tp, struct tcphdr *th)
{
if ((tp->ecn_flags&TCP_ECN_OK) && (!th->ece || th->cwr))
--- linux-2.6.12-rc3-mm3-full/net/ipv4/tcp_input.c.old 2005-05-05 21:24:11.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/tcp_input.c 2005-05-05 21:25:04.000000000 +0200
@@ -183,13 +183,26 @@
tp->ack.quick = min(quickacks, TCP_MAX_QUICKACKS);
}
-void tcp_enter_quickack_mode(struct tcp_sock *tp)
+static void tcp_enter_quickack_mode(struct tcp_sock *tp)
{
tcp_incr_quickack(tp);
tp->ack.pingpong = 0;
tp->ack.ato = TCP_ATO_MIN;
}
+static inline void TCP_ECN_check_ce(struct tcp_sock *tp, struct sk_buff *skb)
+{
+ if (tp->ecn_flags&TCP_ECN_OK) {
+ if (INET_ECN_is_ce(TCP_SKB_CB(skb)->flags))
+ tp->ecn_flags |= TCP_ECN_DEMAND_CWR;
+ /* Funny extension: if ECT is not set on a segment,
+ * it is surely retransmit. It is not in ECN RFC,
+ * but Linux follows this rule. */
+ else if (INET_ECN_is_not_ect((TCP_SKB_CB(skb)->flags)))
+ tcp_enter_quickack_mode(tp);
+ }
+}
+
/* Send ACKs quickly, if "quick" count is not exhausted
* and the session is not interactive.
*/
--- linux-2.6.12-rc3-mm3-full/include/net/xfrm.h.old 2005-05-05 21:26:56.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/include/net/xfrm.h 2005-05-05 21:27:01.000000000 +0200
@@ -799,7 +799,6 @@
extern void xfrm6_fini(void);
extern void xfrm_state_init(void);
extern void xfrm4_state_init(void);
-extern void xfrm4_state_fini(void);
extern void xfrm6_state_init(void);
extern void xfrm6_state_fini(void);
--- linux-2.6.12-rc3-mm3-full/net/ipv4/xfrm4_state.c.old 2005-05-05 21:27:09.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/xfrm4_state.c 2005-05-05 21:27:24.000000000 +0200
@@ -119,8 +119,10 @@
xfrm_state_register_afinfo(&xfrm4_state_afinfo);
}
+#if 0
void __exit xfrm4_state_fini(void)
{
xfrm_state_unregister_afinfo(&xfrm4_state_afinfo);
}
+#endif /* 0 */
--- linux-2.6.12-rc3-mm3-full/net/ipv4/fib_frontend.c.old 2005-05-05 21:38:28.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/fib_frontend.c 2005-05-05 21:38:40.000000000 +0200
@@ -607,5 +607,4 @@
}
EXPORT_SYMBOL(inet_addr_type);
-EXPORT_SYMBOL(ip_dev_find);
EXPORT_SYMBOL(ip_rt_ioctl);
--- linux-2.6.12-rc3-mm3-full/net/ipv4/inetpeer.c.old 2005-05-05 21:41:06.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/inetpeer.c 2005-05-05 21:41:14.000000000 +0200
@@ -456,5 +456,3 @@
peer_total / inet_peer_threshold * HZ;
add_timer(&peer_periodic_timer);
}
-
-EXPORT_SYMBOL(inet_peer_idlock);
--- linux-2.6.12-rc3-mm3-full/net/ipv4/ip_options.c.old 2005-05-05 21:42:02.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/ip_options.c 2005-05-05 21:42:33.000000000 +0200
@@ -620,6 +620,3 @@
}
return 0;
}
-
-EXPORT_SYMBOL(ip_options_compile);
-EXPORT_SYMBOL(ip_options_undo);
--- linux-2.6.12-rc3-mm3-full/net/ipv4/tcp_ipv4.c.old 2005-05-05 21:58:55.000000000 +0200
+++ linux-2.6.12-rc3-mm3-full/net/ipv4/tcp_ipv4.c 2005-05-05 21:59:33.000000000 +0200
@@ -2660,7 +2660,6 @@
EXPORT_SYMBOL(tcp_proc_unregister);
#endif
EXPORT_SYMBOL(sysctl_local_port_range);
-EXPORT_SYMBOL(sysctl_max_syn_backlog);
EXPORT_SYMBOL(sysctl_tcp_low_latency);
EXPORT_SYMBOL(sysctl_tcp_tw_reuse);
^ 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