* Re: [patch 5] softmac: report when scanning has finished
From: Dan Williams @ 2006-04-13 12:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, John W. Linville, softmac-dev
In-Reply-To: <1144921288.4187.54.camel@localhost>
On Thu, 2006-04-13 at 11:41 +0200, Johannes Berg wrote:
> Make softmac report a scan event when scanning has finished, that way
> userspace can wait for the event to happen instead of polling for the
> results.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
ACK, good catch.
Signed-off-by: Dan Williams <dcbw@redhat.com>
> ---
> This patch depends on the previous patch 4. If you want, I can resend
> the whole series with proper patch x/5 headers etc. I don't know if
> these can still go in before .17, but it'd be very good if they could,
> they're essentially bug fixes for things I either didn't know or just
> plain bugs :)
>
> Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_event.c
> ===================================================================
> --- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_event.c 2006-04-13 02:42:59.000000000 +0200
> +++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_event.c 2006-04-13 11:30:59.896998787 +0200
> @@ -152,6 +152,12 @@
> wrqu.ap_addr.sa_family = ARPHRD_ETHER;
> we_event = SIOCGIWAP;
> break;
> + case IEEE80211SOFTMAC_EVENT_SCAN_FINISHED:
> + wrqu.data.length = 0;
> + wrqu.data.flags = 0;
> + memset(&wrqu, '\0', sizeof (union iwreq_data));
> + we_event = SIOCGIWSCAN;
> + break;
> default:
> msg = event_descriptions[event];
> wrqu.data.length = strlen(msg);
>
^ permalink raw reply
* Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning
From: Dan Williams @ 2006-04-13 12:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: Pete Zaitcev, Jean Tourrilhes, netdev, softmac-dev
In-Reply-To: <1144920890.4187.50.camel@localhost>
On Thu, 2006-04-13 at 11:34 +0200, Johannes Berg wrote:
> On Thu, 2006-04-13 at 11:06 +0200, Johannes Berg wrote:
>
> > > It's very likely that tools do indeed loop when they see EAGAIN, but
> > > this is a workaround, not the main mode of operation. It seems obvious
> > > to me that the get method should wait until the scan results are
> > > available. Perhaps the discussion had a specific scenario where
> > > EAGAIN would make sense, but I cannot imagine what it might be.
> >
> > Right, they do loop, but they don't have a method to indicate
> > completion. Thus we'd have to actually wait for the completion in the
> > kernel. Jean, what is the intended use here?
>
> Hah, never mind, I guess we're just supposed to send SIOCGIWSCAN. Will
> send a patch in a minute.
No, you should be doing both really. If you don't do EAGAIN, then tools
like iwlist and other simple ones that don't want to spend 100 lines of
code in netlink message processing just to receive the wireless event
won't work very well.
Dan
^ permalink raw reply
* Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning
From: Johannes Berg @ 2006-04-13 12:19 UTC (permalink / raw)
To: Dan Williams; +Cc: Pete Zaitcev, netdev, linville, softmac-dev
In-Reply-To: <1144930375.2372.10.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]
On Thu, 2006-04-13 at 08:12 -0400, Dan Williams wrote:
> Maybe it's wrong now, but it's how the CLI tools have operated for quite
> a while AFAIK.
Yes, and they don't seem to care about the netlink messages.
But the question is rather -- should we block the program inside the
kernel and only return from "get scan" after the scan is actually done,
rather than returning "we can't give you anything now, try later". We
could do that too, but then the program would be blocked inside the
kernel without any chance of saying "bah, this takes too long, I'll
ignore it".
> There are two options for tools: (a) request scan and block on GIWSCAN
> until it doesn't return EAGAIN, or (b) request a scan, enter a loop,
> wait for the GIWSCAN netlink message to come back. The point here is
> that if you have to write a tool with 100 lines of netlink message
> processing code _just_ to get the "scan done!" message, that's a bitch.
> More complicated programs can obviously do this, but simple tools don't
> want or need to.
Yeah, I just implemented that in softmac too (patch 5 of my set), so you
can just request a scan and do nothing until you are notified that the
netlink message came in that scanning is done.
> airo, atmel, and orinoco all do this. ipw does not, and prism54 does
> not because it does background scanning. I believe that the patch for
> softmac/bcm43xx EAGAIN is correct.
Good. I hope that these can go in before 2.6.17.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] atm: clip causes unregister hang
From: Herbert Xu @ 2006-04-13 12:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, chas, linux-atm-general, netdev, stable
In-Reply-To: <20060412145254.4dd21be6@localhost.localdomain>
On Wed, Apr 12, 2006 at 02:52:54PM -0700, Stephen Hemminger wrote:
> If Classical IP over ATM module is loaded, its neighbor table gets
> populated when permanent neighbor entries are created; but these entries
> are not flushed when the device is removed. Since the entry never gets
> flushed the unregister of the network device never completes.
>
> This version of the patch also adds locking around the reference to
> the atm arp daemon to avoid races with events and daemon state changes.
> (Note: barrier() was never really safe)
>
> Bug-reference: http://bugzilla.kernel.org/show_bug.cgi?id=6295
> Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Thanks a lot Stephen. This version looks good.
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
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/core/: possible cleanups
From: Jörn Engel @ 2006-04-13 12:30 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev
In-Reply-To: <20060413115828.GD8171@stusta.de>
On Thu, 13 April 2006 13:58:28 +0200, Adrian Bunk wrote:
>
> - make the following trivial wrapper function a static inline:
> - neighbour.c: neigh_parms_destroy()
Am I missing something or is there just a single caller? In that
case, neigh_parms_put() could call kfree() directly and
neigh_parms_destroy() is free for termination.
Jörn
--
"[One] doesn't need to know [...] how to cause a headache in order
to take an aspirin."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
^ permalink raw reply
* Re: [PATCH] acxsm: Reduce the number of ACX_PACKED instructions
From: Denis Vlasenko @ 2006-04-13 12:33 UTC (permalink / raw)
To: John W. Linville; +Cc: Carlos Martin, netdev, acx100-devel
In-Reply-To: <20060412205756.GD12788@tuxdriver.com>
On Wednesday 12 April 2006 23:58, John W. Linville wrote:
> On Sat, Mar 25, 2006 at 09:01:16PM +0100, Carlos Martin wrote:
> > Up to now, we were using ACX_PACKED after every field. I've finally
> > found out how to use only one at the end of each struct whilst
> > maintaining the typedef where it is now.
> >
> > This should also apply to acx with a bit of fuzz, but I consider it to
> > be in maintenance mode, so this doesn't qualify for it.
> >
> > Signed-off-by: Carlos Martin <carlos@cmartin.tk>
> >
> > ---
> >
> > acx_struct.h | 874 +++++++++++++++++++++++++++++-----------------------------
> > common.c | 26 +-
> > ioctl.c | 10 -
> > usb.c | 8 -
> > 4 files changed, 457 insertions(+), 461 deletions(-)
> >
> > 5fb2fdfd8c028a40921bbf9ef7ec4c53c03fcab4
> > diff --git a/acx_struct.h b/acx_struct.h
>
> Denis, have you got this patch? Or do I need to apply it?
I tried to sync with your git tree, but:
Sometime ago I downloaded softmac git tree with
# cg-branch-add r-softmac 'rsync://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git#softmac'
but today I can't update from that:
# cg-update r-softmac
Recovering from a previously interrupted fetch...
WARNING: The rsync access method is DEPRECATED and will be REMOVED in the future!
Fetching head...
MOTD:
MOTD: Welcome to the Linux Kernel Archive.
MOTD:
MOTD: Due to U.S. Exports Regulations, all cryptographic software on this
MOTD: site is subject to the following legal notice:
MOTD:
MOTD: This site includes publicly available encryption source code
MOTD: which, together with object code resulting from the compiling of
MOTD: publicly available source code, may be exported from the United
MOTD: States under License Exception "TSU" pursuant to 15 C.F.R. Section
MOTD: 740.13(e).
MOTD:
MOTD: This legal notice applies to cryptographic software only.
MOTD: Please see the Bureau of Industry and Security,
MOTD: http://www.bis.doc.gov/ for more information about current
MOTD: U.S. regulations.
MOTD:
receiving file list ... done
sent 4 bytes received 9 bytes 0.36 bytes/sec
total size is 0 speedup is 0.00
cg-fetch: unable to get the head pointer of branch softmac
Did you rename softmac branch again?
--
vda
^ permalink raw reply
* Re: [PATCH] atm: clip timer race
From: Herbert Xu @ 2006-04-13 12:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, chas, linux-atm-general, netdev
In-Reply-To: <20060412154214.1dd4117d@localhost.localdomain>
On Wed, Apr 12, 2006 at 03:42:14PM -0700, Stephen Hemminger wrote:
> By inspection, the clip idle timer code is racy on SMP.
> Here is a safe version of timer management.
> Untested, I don't have ATM hardware.
Good catch Stephen.
> - if (start_timer == 0)
> - del_timer(&idle_timer);
> + del_timer_sync(&idle_timer);
I don't think this is enough though since this timer is one of those
self-rescheduling timers. You need to provide some sort of a flag
for it to stop scheduling itself and synchronise it properly.
Of course this is an existing bug but we might as well squash it
before we forget about it.
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
^ permalink raw reply
* [XFRM] Fix aevent timer
From: jamal @ 2006-04-13 12:55 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Herbert Xu, KOVACS Krisztian
[-- Attachment #1: Type: text/plain, Size: 193 bytes --]
Finally got an opportunity to test this. I have incorporated all the
feedback and it passes all the scenarios i know.
Dave, please apply to Linus tree since this is a bug fix.
cheers,
jamal
[-- Attachment #2: aevent-fix-timer-5 --]
[-- Type: text/plain, Size: 2761 bytes --]
Send aevent immediately if we have sent nothing since last timer and
this is the first packet.
Fixes a corner case when packet threshold is very high, the timer low
and a very low packet rate input which is bursty.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
include/net/xfrm.h | 8 ++++++++
net/xfrm/xfrm_state.c | 25 +++++++++++++++++++------
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 0d5529c..b77d333 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -143,6 +143,11 @@ struct xfrm_state
/* Replay detection state at the time we sent the last notification */
struct xfrm_replay_state preplay;
+ /* internal flag that only holds state for delayed aevent at the
+ * moment
+ */
+ u32 xflags;
+
/* Replay detection notification settings */
u32 replay_maxage;
u32 replay_maxdiff;
@@ -167,6 +172,9 @@ struct xfrm_state
* interpreted by xfrm_type methods. */
void *data;
};
+
+/* xflags - make enum if more show up */
+#define XFRM_TIME_DEFER 1
enum {
XFRM_STATE_VOID,
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index a8e14dc..3dc3e1f 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -805,16 +805,22 @@ void xfrm_replay_notify(struct xfrm_stat
case XFRM_REPLAY_UPDATE:
if (x->replay_maxdiff &&
(x->replay.seq - x->preplay.seq < x->replay_maxdiff) &&
- (x->replay.oseq - x->preplay.oseq < x->replay_maxdiff))
- return;
+ (x->replay.oseq - x->preplay.oseq < x->replay_maxdiff)) {
+ if (x->xflags & XFRM_TIME_DEFER)
+ event = XFRM_REPLAY_TIMEOUT;
+ else
+ return;
+ }
break;
case XFRM_REPLAY_TIMEOUT:
if ((x->replay.seq == x->preplay.seq) &&
(x->replay.bitmap == x->preplay.bitmap) &&
- (x->replay.oseq == x->preplay.oseq))
+ (x->replay.oseq == x->preplay.oseq)) {
+ x->xflags |= XFRM_TIME_DEFER;
return;
+ }
break;
}
@@ -825,8 +831,10 @@ void xfrm_replay_notify(struct xfrm_stat
km_state_notify(x, &c);
if (x->replay_maxage &&
- !mod_timer(&x->rtimer, jiffies + x->replay_maxage))
+ !mod_timer(&x->rtimer, jiffies + x->replay_maxage)) {
xfrm_state_hold(x);
+ x->xflags &= ~XFRM_TIME_DEFER;
+ }
}
EXPORT_SYMBOL(xfrm_replay_notify);
@@ -836,10 +844,15 @@ static void xfrm_replay_timer_handler(un
spin_lock(&x->lock);
- if (xfrm_aevent_is_on() && x->km.state == XFRM_STATE_VALID)
- xfrm_replay_notify(x, XFRM_REPLAY_TIMEOUT);
+ if (x->km.state == XFRM_STATE_VALID) {
+ if (xfrm_aevent_is_on())
+ xfrm_replay_notify(x, XFRM_REPLAY_TIMEOUT);
+ else
+ x->xflags |= XFRM_TIME_DEFER;
+ }
spin_unlock(&x->lock);
+ xfrm_state_put(x);
}
int xfrm_replay_check(struct xfrm_state *x, u32 seq)
^ permalink raw reply related
* Re: [RFC][PATCH] Avoid multi-page allocs for large mtu datagram sends
From: Herbert Xu @ 2006-04-13 12:57 UTC (permalink / raw)
To: Zach Brown; +Cc: netdev
In-Reply-To: <20060405175102.GA28166@tetsuo.zabbo.net>
Hi Zach:
On Wed, Apr 05, 2006 at 05:51:02PM +0000, Zach Brown wrote:
>
> + if ((rt->u.dst.dev->features&NETIF_F_SG) &&
> + (SKB_DATA_KMALLOC_BYTES(alloclen + datalen)
> + > PAGE_SIZE)) {
> + /*
> + * datalen is shrinking so there won't be a
> + * trailer, but alloclen already accounted for
> + * it. use that space for payload but only if
> + * it wasn't the trailer_len itself that pushed
> + * the alloc beyond a single page.
> + */
> + if (datalen - SKB_MAX_ORDER(alloclen, 0) >
> + rt->u.dst.trailer_len)
> + alloclen -= rt->u.dst.trailer_len;
I think this should be done unconditionally. First of all at this
time ESP doesn't know how to deal with this anyway so it's just going
to reallocate and linearise the whole thing. However, when we do fix
it we can just get it to allocate the trailer in its own frag so we
don't need to worry about trailer_len at all.
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
^ permalink raw reply
* [XFRM Doc]: aevent description
From: jamal @ 2006-04-13 13:00 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: KOVACS Krisztian, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 205 bytes --]
Dave,
There is dependency on the previous patch i sent since the issue that
patch fixes is assumed in this text description. It would be a good
idea to apply at the same time as the other.
cheers,
jamal
[-- Attachment #2: xfrm_sync_txt --]
[-- Type: text/plain, Size: 7234 bytes --]
Documentation to describe asynchronous xfrm events to help people
writting HA code in user space.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
Documentation/networking/xfrm_sync.txt | 166 ++++++++++++++++++++++++++++++++
1 files changed, 166 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt
new file mode 100644
index 0000000..8f474aa
--- /dev/null
+++ b/Documentation/networking/xfrm_sync.txt
@@ -0,0 +1,166 @@
+
+The sync patches work is based on initial patches from
+Krisztian <hidden@balabit.hu> and others and additional patches
+from Jamal <hadi@cyberus.ca>.
+
+The end goal for syncing is to be able to insert attributes + generate
+events so that the an SA can be safely moved from one machine to another
+for HA purposes.
+The idea is to synchronize the SA so that the takeover machine can do
+the processing of the SA as accurate as possible if it has access to it.
+
+We already have the ability to generate SA add/del/upd events.
+These patches add ability to sync and have accurate lifetime byte (to
+ensure proper decay of SAs) and replay counters to avoid replay attacks
+with as minimal loss at failover time.
+This way a backup stays as closely uptodate as an active member.
+
+Because the above items change for every packet the SA receives,
+it is possible for a lot of the events to be generated.
+For this reason, we also add a nagle-like algorithm to restrict
+the events. i.e we are going to set thresholds to say "let me
+know if the replay sequence threshold is reached or 10 secs have passed"
+These thresholds are set system-wide via sysctls or can be updated
+per SA.
+
+The identified items that need to be synchronized are:
+- the lifetime byte counter
+note that: lifetime time limit is not important if you assume the failover
+machine is known ahead of time since the decay of the time countdown
+is not driven by packet arrival.
+- the replay sequence for both inbound and outbound
+
+1) Message Structure
+----------------------
+
+nlmsghdr:aevent_id:optional-TLVs.
+
+The netlink message types are:
+
+XFRM_MSG_NEWAE and XFRM_MSG_GETAE.
+
+A XFRM_MSG_GETAE does not have TLVs.
+A XFRM_MSG_NEWAE will have at least two TLVs (as is
+discussed further below).
+
+aevent_id structure looks like:
+
+ struct xfrm_aevent_id {
+ struct xfrm_usersa_id sa_id;
+ __u32 flags;
+ };
+
+xfrm_usersa_id in this message layout identifies the SA.
+
+flags are used to indicate different things. The possible
+flags are:
+ XFRM_AE_RTHR=1, /* replay threshold*/
+ XFRM_AE_RVAL=2, /* replay value */
+ XFRM_AE_LVAL=4, /* lifetime value */
+ XFRM_AE_ETHR=8, /* expiry timer threshold */
+ XFRM_AE_CR=16, /* Event cause is replay update */
+ XFRM_AE_CE=32, /* Event cause is timer expiry */
+ XFRM_AE_CU=64, /* Event cause is policy update */
+
+How these flags are used is dependent on the direction of the
+message (kernel<->user) as well the cause (config, query or event).
+This is described below in the different messages.
+
+The pid will be set appropriately in netlink to recognize direction
+(0 to the kernel and pid = processid that created the event
+when going from kernel to user space)
+
+A program needs to subscribe to multicast group XFRMNLGRP_AEVENTS
+to get notified of these events.
+
+2) TLVS reflect the different parameters:
+-----------------------------------------
+
+a) byte value (XFRMA_LTIME_VAL)
+This TLV carries the running/current counter for byte lifetime since
+last event.
+
+b)replay value (XFRMA_REPLAY_VAL)
+This TLV carries the running/current counter for replay sequence since
+last event.
+
+c)replay threshold (XFRMA_REPLAY_THRESH)
+This TLV carries the threshold being used by the kernel to trigger events
+when the replay sequence is exceeded.
+
+d) expiry timer (XFRMA_ETIMER_THRESH)
+This is a timer value in milliseconds which is used as the nagle
+value to rate limit the events.
+
+3) Default configurations for the parameters:
+----------------------------------------------
+
+By default these events should be turned off unless there is
+at least one listener registered to listen to the multicast
+group XFRMNLGRP_AEVENTS.
+
+Programs installing SAs will need to specify the two thresholds, however,
+in order to not change existing applications such as racoon
+we also provide default threshold values for these different parameters
+in case they are not specified.
+
+the two sysctls/proc entries are:
+a) /proc/sys/net/core/sysctl_xfrm_aevent_etime
+used to provide default values for the XFRMA_ETIMER_THRESH in incremental
+units of time of 100ms. The default is 10 (1 second)
+
+b) /proc/sys/net/core/sysctl_xfrm_aevent_rseqth
+used to provide default values for XFRMA_REPLAY_THRESH parameter
+in incremental packet count. The default is two packets.
+
+4) Message types
+----------------
+
+a) XFRM_MSG_GETAE issued by user-->kernel.
+XFRM_MSG_GETAE does not carry any TLVs.
+The response is a XFRM_MSG_NEWAE which is formatted based on what
+XFRM_MSG_GETAE queried for.
+The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
+*if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved
+*if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved
+
+b) XFRM_MSG_NEWAE is issued by either user space to configure
+or kernel to announce events or respond to a XFRM_MSG_GETAE.
+
+i) user --> kernel to configure a specific SA.
+any of the values or threshold parameters can be updated by passing the
+appropriate TLV.
+A response is issued back to the sender in user space to indicate success
+or failure.
+In the case of success, additionally an event with
+XFRM_MSG_NEWAE is also issued to any listeners as described in iii).
+
+ii) kernel->user direction as a response to XFRM_MSG_GETAE
+The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
+The threshold TLVs will be included if explicitly requested in
+the XFRM_MSG_GETAE message.
+
+iii) kernel->user to report as event if someone sets any values or
+thresholds for an SA using XFRM_MSG_NEWAE (as described in #i above).
+In such a case XFRM_AE_CU flag is set to inform the user that
+the change happened as a result of an update.
+The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
+
+iv) kernel->user to report event when replay threshold or a timeout
+is exceeded.
+In such a case either XFRM_AE_CR (replay exceeded) or XFRM_AE_CE (timeout
+happened) is set to inform the user what happened.
+Note the two flags are mutually exclusive.
+The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
+
+Exceptions to threshold settings
+--------------------------------
+
+If you have an SA that is getting hit by traffic in bursts such that
+there is a period where the timer threshold expires with no packets
+seen, then an odd behavior is seen as follows:
+The first packet arrival after a timer expiry will trigger a timeout
+aevent; i.e we dont wait for a timeout period or a packet threshold
+to be reached. This is done for simplicity and efficiency reasons.
+
+-JHS
^ permalink raw reply related
* [PATCH] bcm43xx: iw_priv_args names should be <16 characters
From: Erik Mouw @ 2006-04-13 13:02 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: netdev
The room for the names in bcm43xx_priv_wx_args[] are IFNAMSIZ long and
IFNAMSIZ is defined as 16, so the names in bcm43xx_priv_wx_args should
be 15 characters (16 including the trailing \0). This patch fixes that
for the "set_shortpreambl", "get_shortpreambl", "set_swencryption", and
"get_swencryption" private calls. Patch is against 2.6.17-rc1.
Signed-off-by: Erik Mouw <erik@harddisk-recovery.com>
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index 3daee82..3edbb48 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -962,22 +962,22 @@ static const struct iw_priv_args bcm43xx
{
.cmd = PRIV_WX_SET_SHORTPREAMBLE,
.set_args = IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1,
- .name = "set_shortpreambl",
+ .name = "set_shortpreamb",
},
{
.cmd = PRIV_WX_GET_SHORTPREAMBLE,
.get_args = IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | MAX_WX_STRING,
- .name = "get_shortpreambl",
+ .name = "get_shortpreamb",
},
{
.cmd = PRIV_WX_SET_SWENCRYPTION,
.set_args = IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1,
- .name = "set_swencryption",
+ .name = "set_swencrypt",
},
{
.cmd = PRIV_WX_GET_SWENCRYPTION,
.get_args = IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | MAX_WX_STRING,
- .name = "get_swencryption",
+ .name = "get_swencrypt",
},
{
.cmd = PRIV_WX_SPROM_WRITE,
^ permalink raw reply related
* Re: [PATCH] acxsm: Reduce the number of ACX_PACKED instructions
From: John W. Linville @ 2006-04-13 13:08 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: Carlos Martin, netdev, acx100-devel
In-Reply-To: <200604131533.57478.vda@ilport.com.ua>
On Thu, Apr 13, 2006 at 03:33:57PM +0300, Denis Vlasenko wrote:
> Did you rename softmac branch again?
I'm trying to reduce the branches. Some/most of what was the softmac
branch has been merged upstream. The tiacx and prism54usb drivers
remain in wireless-2.6 under the "master" branch.
BTW, the consensus at the wifi summit was that the remaining softmac
drivers should be merged upstream as sson as the basic coding issues
(compiles w/o warnings, follows kernel style, etc) are resolved.
Actually "working" is not a solid requirement.
With that in mind, I would appreciate it if you (and any other
interested party) would begin reviewing the code with the intent to
get it merged in the next cycle.
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: tc actions like pass,drop executed at a given percentage, not every nth
From: jamal @ 2006-04-13 13:17 UTC (permalink / raw)
To: pfer; +Cc: netdev
In-Reply-To: <20060411154259.77190.qmail@web54301.mail.yahoo.com>
On Tue, 2006-11-04 at 08:42 -0700, pfer wrote:
> Hi all!
>
> Can you give me some guideline about how and where
> netrand ... influences an action in the tc sources?
>
> (I've also tried LARTC mailing list, but did not get
> any response)
>
Did you look at the docs included in iproute2?
> When I last checked, iproute2 sources had a tc gact
> module with 2 statistical netrand methods:
>
> - random
> - determ
>
> and both are followed by an integer, saying what to do
> with every n-th packet (if I get it right from docs
> and tc filter show)
>
> Problem is, I would need % of packets to do actions
> on, not on every n-th. This limits me to
> 50,33,25,20,... etc % ratios, because I cannot write
> for. ex.
>
> action drop random determ 1.23 ok
>
right.
> So, basically I believe I would need something like
> this in pseudo:
>
> for every packet
> if(rand()<(percent/100))
> do_action
>
> ,where rand() gives a float of 0..1
>
We dont like floats in the kernel - but i think i understand the
gist of what you want to achieve.
> Or if doing a rand() for every packet is costy,
> then I could decrease granularity by 2 or 5, etc.
> Still,I would get the ratio.
>
> I delved into the sources, but was unable to find
> where
> this conditional (for every n-th packet) tc action
> execution occurs.
>
The control code is in iproute2:
iproute2/tc/m_gact.c
The mechanisms are implemented in the kernel:
net/sched/act_gact.c
Just follow the trail of #ifdef CONFIG_GACT_PROB
both in user space and in the kernel.
You would need to add another method for % in addition to
gact_net_rand() and gact_determ()
You may actually be able to achieve your goal by picking the right
number for determ (we restrict the max to be 10000)
If you cant achieve your goal with determ - I would be more than happy
to ACK a patch that does percentages.
> (If anyone is interested, I need this for a protocol
> that uses a strange congestion signaling method to let
> intra-domain nodes notify edges, based on packet ratio
> having different DSCP. The name is RMD-QoS-NSLP)
>
Cool.
Shoot me private email if you need help since this is really out of
scope of netdev
cheers,
jamal
^ permalink raw reply
* Re: [XFRM] Fix aevent timer
From: Herbert Xu @ 2006-04-13 13:46 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev, KOVACS Krisztian
In-Reply-To: <1144932959.5262.5.camel@jzny2>
On Thu, Apr 13, 2006 at 08:55:58AM -0400, jamal wrote:
>
> Finally got an opportunity to test this. I have incorporated all the
> feedback and it passes all the scenarios i know.
Looks good to me. Thanks Jamal.
--
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
^ permalink raw reply
* Re: [PATCH] deinline a few large functions in vlan code v2
From: Dave Dillow @ 2006-04-13 14:59 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: netdev, David S. Miller, linux-kernel, jgarzik
In-Reply-To: <200604130904.57054.vda@ilport.com.ua>
On Thu, 2006-04-13 at 09:04 +0300, Denis Vlasenko wrote:
> On Wednesday 12 April 2006 20:18, Dave Dillow wrote:
> > > > or loaded. And even if it saves 200 bytes in one
> > > > module, unless that module text was already less than 200 bytes into a
> > > > page, you've saved no memory -- a 4300 byte module takes 2 pages on x86,
> > > > as does a 4100 byte module.
> > >
> > > Sometimes, those 200 bytes can bring module size just under 4096.
> > > Thus on the average, on many modules you get the same size savings
> > > as on built-in code. (Not that we have THAT many network modules...)
> >
> > You're making a bogus leap from "sometimes" to "average".
>
> It's not bogus. See below.
My bad, I used a different notion of "average". You're using a
mathematical definition, and are of course correct in that case.
But to get your average, you have to either build all modules in, or
load every module. I'm saying the "average" user won't do that.
> IOW: currently most of VLAN code is already in kernel.
No, I'm saying most of the code is in 8021q.ko. The exceptions are the
big inlines you targeted, and I agree with moving them out-of-line.
--
Dave Dillow <dave@thedillows.org>
^ permalink raw reply
* Re: [RFD][PATCH] typhoon and core sample for folding away VLAN stuff
From: Dave Dillow @ 2006-04-13 15:00 UTC (permalink / raw)
To: Denis Vlasenko
Cc: Ingo Oeser, Ingo Oeser, netdev, David S. Miller, linux-kernel,
jgarzik
In-Reply-To: <200604131138.59611.vda@ilport.com.ua>
On Thu, 2006-04-13 at 11:38 +0300, Denis Vlasenko wrote:
> On Thursday 13 April 2006 04:24, Dave Dillow wrote:
> > Regardless, I remain opposed to this particular instance of bloat
> > busting. While both patches have improved in style, they remove a useful
> > feature and make the code less clean, for no net gain.
>
> What happened to non-modular build? "no net gain" is not true.
Ok, so you saved what, 200 bytes? On a few drivers that may save you a
small amount -- you basically said you had to have everything loaded to
see 5K.
Weren't most of those savings from moving a big function out-of-line?
The part I agree with?
> > > This kind of changes are important, because bloat creeps in byte by byte
> > > of unused features. So I really appreciate your work here Denis.
> >
> > On SMP FC4, typhoon.ko has a text size of 68330, so you need to cut 2794
> > bytes to see an actual difference in memory usage for a module. Non-SMP
> > it is 67741, so there you only need to cut 2205 bytes to get a win.
>
> This is silly. Should I go this route and try a dozen of different gcc
> versions and "-O2 versus -Os" things to demonstrate that sometimes
> it will matter?
Quit being dense. No one has said that there are cases will it make a
difference, just that that case is far removed from the usual case.
I think I'm done on this topic. You've got more important people to
convince than me, and they've already clear stated their position.
--
Dave Dillow <dave@thedillows.org>
^ permalink raw reply
* Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning
From: Jouni Malinen @ 2006-04-13 16:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: Dan Williams, Pete Zaitcev, netdev, linville, softmac-dev
In-Reply-To: <1144930766.4187.80.camel@localhost>
On Thu, Apr 13, 2006 at 02:19:26PM +0200, Johannes Berg wrote:
> But the question is rather -- should we block the program inside the
> kernel and only return from "get scan" after the scan is actually done,
> rather than returning "we can't give you anything now, try later". We
> could do that too, but then the program would be blocked inside the
> kernel without any chance of saying "bah, this takes too long, I'll
> ignore it".
Please don't. That could be blocking an ioctl call for couple of seconds
and would be quite horrible for single threaded programs. It is possible
to wait for scan completion events, but what if some other program were
to request a new scan between the completion event and the attempt to
read the previous scan results..
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning
From: Jean Tourrilhes @ 2006-04-13 16:13 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, Pete Zaitcev, netdev, softmac-dev
In-Reply-To: <1144930441.2372.12.camel@localhost.localdomain>
On Thu, Apr 13, 2006 at 08:14:01AM -0400, Dan Williams wrote:
> On Thu, 2006-04-13 at 11:34 +0200, Johannes Berg wrote:
> > On Thu, 2006-04-13 at 11:06 +0200, Johannes Berg wrote:
> >
> > > > It's very likely that tools do indeed loop when they see EAGAIN, but
> > > > this is a workaround, not the main mode of operation. It seems obvious
> > > > to me that the get method should wait until the scan results are
> > > > available. Perhaps the discussion had a specific scenario where
> > > > EAGAIN would make sense, but I cannot imagine what it might be.
> > >
> > > Right, they do loop, but they don't have a method to indicate
> > > completion. Thus we'd have to actually wait for the completion in the
> > > kernel. Jean, what is the intended use here?
> >
> > Hah, never mind, I guess we're just supposed to send SIOCGIWSCAN. Will
> > send a patch in a minute.
>
> No, you should be doing both really. If you don't do EAGAIN, then tools
> like iwlist and other simple ones that don't want to spend 100 lines of
> code in netlink message processing just to receive the wireless event
> won't work very well.
>
> Dan
Yes, Dan is 100% correct.
Jean
^ permalink raw reply
* [RFC: 2.6 patch] net/netlink/: possible cleanups
From: Adrian Bunk @ 2006-04-13 16:27 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch contains the following possible cleanups plus changes related
to them:
- make the following needlessly global functions static:
- attr.c: __nla_reserve()
- attr.c: __nla_put()
- #if 0 the following unused global functions:
- attr.c: nla_validate()
- attr.c: nla_find()
- attr.c: nla_memcpy()
- attr.c: nla_memcmp()
- attr.c: nla_strcmp()
- attr.c: nla_reserve()
- genetlink.c: genl_unregister_ops()
- remove the following unused EXPORT_SYMBOL's:
- af_netlink.c: netlink_set_nonroot
- attr.c: nla_parse
- attr.c: nla_strlcpy
- attr.c: nla_put
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/net/genetlink.h | 1 -
include/net/netlink.h | 23 ++++++++---------------
net/netlink/af_netlink.c | 1 -
net/netlink/attr.c | 29 ++++++++++++++---------------
net/netlink/genetlink.c | 3 ++-
5 files changed, 24 insertions(+), 33 deletions(-)
--- linux-2.6.17-rc1-mm2-full/net/netlink/af_netlink.c.old 2006-04-13 17:40:48.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/net/netlink/af_netlink.c 2006-04-13 17:40:56.000000000 +0200
@@ -1805,7 +1805,6 @@
EXPORT_SYMBOL(netlink_kernel_create);
EXPORT_SYMBOL(netlink_register_notifier);
EXPORT_SYMBOL(netlink_set_err);
-EXPORT_SYMBOL(netlink_set_nonroot);
EXPORT_SYMBOL(netlink_unicast);
EXPORT_SYMBOL(netlink_unregister_notifier);
--- linux-2.6.17-rc1-mm2-full/include/net/netlink.h.old 2006-04-13 17:42:48.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/include/net/netlink.h 2006-04-13 17:53:51.000000000 +0200
@@ -189,24 +189,11 @@
extern void netlink_queue_skip(struct nlmsghdr *nlh,
struct sk_buff *skb);
-extern int nla_validate(struct nlattr *head, int len, int maxtype,
- struct nla_policy *policy);
extern int nla_parse(struct nlattr *tb[], int maxtype,
struct nlattr *head, int len,
struct nla_policy *policy);
-extern struct nlattr * nla_find(struct nlattr *head, int len, int attrtype);
extern size_t nla_strlcpy(char *dst, const struct nlattr *nla,
size_t dstsize);
-extern int nla_memcpy(void *dest, struct nlattr *src, int count);
-extern int nla_memcmp(const struct nlattr *nla, const void *data,
- size_t size);
-extern int nla_strcmp(const struct nlattr *nla, const char *str);
-extern struct nlattr * __nla_reserve(struct sk_buff *skb, int attrtype,
- int attrlen);
-extern struct nlattr * nla_reserve(struct sk_buff *skb, int attrtype,
- int attrlen);
-extern void __nla_put(struct sk_buff *skb, int attrtype,
- int attrlen, const void *data);
extern int nla_put(struct sk_buff *skb, int attrtype,
int attrlen, const void *data);
@@ -331,6 +318,8 @@
nlmsg_attrlen(nlh, hdrlen), policy);
}
+#if 0
+
/**
* nlmsg_find_attr - find a specific attribute in a netlink message
* @nlh: netlink message header
@@ -374,7 +363,6 @@
nla_for_each_attr(pos, nlmsg_attrdata(nlh, hdrlen), \
nlmsg_attrlen(nlh, hdrlen), rem)
-#if 0
/* FIXME: Enable once all users have been converted */
/**
@@ -407,7 +395,8 @@
return nlh;
}
-#endif
+
+#endif /* 0 */
/**
* nlmsg_put - Add a new netlink message to an skb
@@ -784,6 +773,7 @@
return *(u8 *) nla_data(nla);
}
+#if 0
/**
* nla_get_u64 - return payload of u64 attribute
* @nla: u64 netlink attribute
@@ -796,6 +786,7 @@
return tmp;
}
+#endif /* 0 */
/**
* nla_get_flag - return payload of flag attribute
@@ -806,6 +797,7 @@
return !!nla;
}
+#if 0
/**
* nla_get_msecs - return payload of msecs attribute
* @nla: msecs netlink attribute
@@ -818,6 +810,7 @@
return msecs_to_jiffies((unsigned long) msecs);
}
+#endif /* 0 */
/**
* nla_nest_start - Start a new level of nested attributes
--- linux-2.6.17-rc1-mm2-full/net/netlink/attr.c.old 2006-04-13 17:44:12.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/net/netlink/attr.c 2006-04-13 17:55:22.000000000 +0200
@@ -52,6 +52,7 @@
return 0;
}
+#if 0
/**
* nla_validate - Validate a stream of attributes
* @head: head of attribute stream
@@ -81,6 +82,7 @@
errout:
return err;
}
+#endif /* 0 */
/**
* nla_parse - Parse a stream of attributes into a tb buffer
@@ -127,6 +129,7 @@
return err;
}
+#if 0
/**
* nla_find - Find a specific attribute in a stream of attributes
* @head: head of attribute stream
@@ -146,6 +149,7 @@
return NULL;
}
+#endif /* 0 */
/**
* nla_strlcpy - Copy string attribute payload into a sized buffer
@@ -177,6 +181,8 @@
return srclen;
}
+#if 0
+
/**
* nla_memcpy - Copy a netlink attribute into another memory area
* @dest: where to copy to memcpy
@@ -230,6 +236,8 @@
return d;
}
+#endif /* 0 */
+
/**
* __nla_reserve - reserve room for attribute on the skb
* @skb: socket buffer to reserve room on
@@ -242,7 +250,8 @@
* The caller is responsible to ensure that the skb provides enough
* tailroom for the attribute header and payload.
*/
-struct nlattr *__nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
+static struct nlattr *__nla_reserve(struct sk_buff *skb, int attrtype,
+ int attrlen)
{
struct nlattr *nla;
@@ -255,6 +264,7 @@
return nla;
}
+#if 0
/**
* nla_reserve - reserve room for attribute on the skb
* @skb: socket buffer to reserve room on
@@ -274,6 +284,7 @@
return __nla_reserve(skb, attrtype, attrlen);
}
+#endif /* 0 */
/**
* __nla_put - Add a netlink attribute to a socket buffer
@@ -285,8 +296,8 @@
* The caller is responsible to ensure that the skb provides enough
* tailroom for the attribute header and payload.
*/
-void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
- const void *data)
+static void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
+ const void *data)
{
struct nlattr *nla;
@@ -314,15 +325,3 @@
return 0;
}
-
-EXPORT_SYMBOL(nla_validate);
-EXPORT_SYMBOL(nla_parse);
-EXPORT_SYMBOL(nla_find);
-EXPORT_SYMBOL(nla_strlcpy);
-EXPORT_SYMBOL(__nla_reserve);
-EXPORT_SYMBOL(nla_reserve);
-EXPORT_SYMBOL(__nla_put);
-EXPORT_SYMBOL(nla_put);
-EXPORT_SYMBOL(nla_memcpy);
-EXPORT_SYMBOL(nla_memcmp);
-EXPORT_SYMBOL(nla_strcmp);
--- linux-2.6.17-rc1-mm2-full/include/net/genetlink.h.old 2006-04-13 17:39:36.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/include/net/genetlink.h 2006-04-13 17:39:50.000000000 +0200
@@ -72,7 +72,6 @@
extern int genl_register_family(struct genl_family *family);
extern int genl_unregister_family(struct genl_family *family);
extern int genl_register_ops(struct genl_family *, struct genl_ops *ops);
-extern int genl_unregister_ops(struct genl_family *, struct genl_ops *ops);
extern struct sock *genl_sock;
--- linux-2.6.17-rc1-mm2-full/net/netlink/genetlink.c.old 2006-04-13 17:39:58.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/net/netlink/genetlink.c 2006-04-13 17:40:13.000000000 +0200
@@ -154,6 +154,7 @@
return err;
}
+#if 0
/**
* genl_unregister_ops - unregister generic netlink operations
* @family: generic netlink family
@@ -187,6 +188,7 @@
return -ENOENT;
}
+#endif /* 0 */
/**
* genl_register_family - register a generic netlink family
@@ -565,6 +567,5 @@
EXPORT_SYMBOL(genl_sock);
EXPORT_SYMBOL(genl_register_ops);
-EXPORT_SYMBOL(genl_unregister_ops);
EXPORT_SYMBOL(genl_register_family);
EXPORT_SYMBOL(genl_unregister_family);
^ permalink raw reply
* Re: [PATCH] atm: clip timer race
From: Stephen Hemminger @ 2006-04-13 17:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, chas, linux-atm-general, netdev
In-Reply-To: <20060413124534.GA25333@gondor.apana.org.au>
On Thu, 13 Apr 2006 22:45:34 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Apr 12, 2006 at 03:42:14PM -0700, Stephen Hemminger wrote:
> > By inspection, the clip idle timer code is racy on SMP.
> > Here is a safe version of timer management.
> > Untested, I don't have ATM hardware.
>
> Good catch Stephen.
>
> > - if (start_timer == 0)
> > - del_timer(&idle_timer);
> > + del_timer_sync(&idle_timer);
>
> I don't think this is enough though since this timer is one of those
> self-rescheduling timers. You need to provide some sort of a flag
> for it to stop scheduling itself and synchronise it properly.
Arp and neighbor table have the same rescheduling bug.
> Of course this is an existing bug but we might as well squash it
> before we forget about it.
>
> Cheers,
^ permalink raw reply
* Re: [PATCH 12/18] ipw2200: version string rework
From: Stephen Hemminger @ 2006-04-13 17:28 UTC (permalink / raw)
To: yi.zhu; +Cc: netdev, John W. Linville
In-Reply-To: <20060413092034.GA28787@mail.intel.com>
On Thu, 13 Apr 2006 17:20:34 +0800
Zhu Yi <yi.zhu@intel.com> wrote:
> Added version string fields so the version string indicates what is
> configured (ie, you'll see 1.1.1kpmd if you are using a GIT snapshot
> (Kernel.. previously -git), promiscuous (p), monitor (m), debug (d) build.
No, this is completely the wrong direction.
Stop with the config option nonsense. It makes it impossible for linux distributions
and others that want to ship one kernel and modules.
^ permalink raw reply
* Re: [PATCH] bcm43xx: iw_priv_args names should be <16 characters
From: Stephen Hemminger @ 2006-04-13 17:29 UTC (permalink / raw)
To: Erik Mouw; +Cc: bcm43xx-dev, netdev
In-Reply-To: <20060413130227.GD20839@harddisk-recovery.nl>
On Thu, 13 Apr 2006 15:02:27 +0200
Erik Mouw <erik@harddisk-recovery.com> wrote:
> The room for the names in bcm43xx_priv_wx_args[] are IFNAMSIZ long and
> IFNAMSIZ is defined as 16, so the names in bcm43xx_priv_wx_args should
> be 15 characters (16 including the trailing \0). This patch fixes that
> for the "set_shortpreambl", "get_shortpreambl", "set_swencryption", and
> "get_swencryption" private calls. Patch is against 2.6.17-rc1.
>
> Signed-off-by: Erik Mouw <erik@harddisk-recovery.com>
Shouldn't compiler have gagged on this?
^ permalink raw reply
* Re: [PATCH] ipw2100: wraps the debug module param within #ifdefs
From: Stephen Hemminger @ 2006-04-13 17:30 UTC (permalink / raw)
To: yi.zhu; +Cc: netdev, John W. Linville
In-Reply-To: <20060413091423.GA28623@mail.intel.com>
Please get rid of the debug config option. Make the debug code, default
off and be low enough impact that everyone can ship with it.
^ permalink raw reply
* Re: [PATCH] atm: clip timer race
From: Herbert Xu @ 2006-04-13 17:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, chas, linux-atm-general, netdev
In-Reply-To: <20060413102630.7748f7b3@localhost.localdomain>
On Thu, Apr 13, 2006 at 10:26:30AM -0700, Stephen Hemminger wrote:
>
> Arp and neighbor table have the same rescheduling bug.
You're absolutely right. Maybe the easy way out for now is to make
clip unremovable.
--
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
^ permalink raw reply
* [PATCH RESEND 1/2] s390: remove tty support from ctc network device driver [1/2]
From: Frank Pavlic @ 2006-04-13 18:19 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Hi jeff,
after the first shot I sent to you did not apply I
resend two new patches I've made today to remove tty from ctc network driver.
Please apply ....
Thank you ...
Frank
From: Peter Tiedemann <ptiedem@de.ibm.com>
[1/2]:
tty support code will be removed from the ctc network device driver.
Today we have a couple of alternatives which are performing much
better. The second thing is that ctc should be a network
device driver only.
We should not mix tty and networking here.
This first patch will remove the tty code from ctcmain.c .
It also removes the build entry from the Makefile as well as TTY
definitions from ctcmain.h.
The second patch will remove two files, ctctty.c and ctctty.h.
Signed-off-by: Frank Pavlic <fpavlic@de.ibm.com>
---
drivers/s390/net/Makefile | 3 ++-
drivers/s390/net/ctcmain.c | 45 +++++++++-----------------------------------
drivers/s390/net/ctcmain.h | 12 +++++-------
3 files changed, 16 insertions(+), 44 deletions(-)
fd1e8730b620e901a223034aaa6d97dde7a63b56
diff --git a/drivers/s390/net/Makefile b/drivers/s390/net/Makefile
index 90d4d0e..6775a83 100644
--- a/drivers/s390/net/Makefile
+++ b/drivers/s390/net/Makefile
@@ -2,7 +2,7 @@
# S/390 network devices
#
-ctc-objs := ctcmain.o ctctty.o ctcdbug.o
+ctc-objs := ctcmain.o ctcdbug.o
obj-$(CONFIG_IUCV) += iucv.o
obj-$(CONFIG_NETIUCV) += netiucv.o fsm.o
@@ -10,6 +10,7 @@ obj-$(CONFIG_SMSGIUCV) += smsgiucv.o
obj-$(CONFIG_CTC) += ctc.o fsm.o cu3088.o
obj-$(CONFIG_LCS) += lcs.o cu3088.o
obj-$(CONFIG_CLAW) += claw.o cu3088.o
+obj-$(CONFIG_MPC) += ctcmpc.o fsm.o cu3088.o
qeth-y := qeth_main.o qeth_mpc.o qeth_sys.o qeth_eddp.o
qeth-$(CONFIG_PROC_FS) += qeth_proc.o
obj-$(CONFIG_QETH) += qeth.o
diff --git a/drivers/s390/net/ctcmain.c b/drivers/s390/net/ctcmain.c
index af9f212..e2ccaf5 100644
--- a/drivers/s390/net/ctcmain.c
+++ b/drivers/s390/net/ctcmain.c
@@ -6,7 +6,7 @@
* Fixes by : Jochen Röhrig (roehrig@de.ibm.com)
* Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Peter Tiedemann (ptiedem@de.ibm.com)
- * Driver Model stuff by : Cornelia Huck <huckc@de.ibm.com>
+ * Driver Model stuff by : Cornelia Huck <cornelia.huck@de.ibm.com>
*
* Documentation used:
* - Principles of Operation (IBM doc#: SA22-7201-06)
@@ -65,7 +65,6 @@
#include <asm/idals.h>
-#include "ctctty.h"
#include "fsm.h"
#include "cu3088.h"
@@ -479,10 +478,7 @@ ctc_unpack_skb(struct channel *ch, struc
skb->dev = pskb->dev;
skb->protocol = pskb->protocol;
pskb->ip_summed = CHECKSUM_UNNECESSARY;
- if (ch->protocol == CTC_PROTO_LINUX_TTY)
- ctc_tty_netif_rx(skb);
- else
- netif_rx_ni(skb);
+ netif_rx_ni(skb);
/**
* Successful rx; reset logflags
*/
@@ -557,8 +553,7 @@ ccw_unit_check(struct channel *ch, unsig
DBF_TEXT(trace, 5, __FUNCTION__);
if (sense & SNS0_INTERVENTION_REQ) {
if (sense & 0x01) {
- if (ch->protocol != CTC_PROTO_LINUX_TTY)
- ctc_pr_debug("%s: Interface disc. or Sel. reset "
+ ctc_pr_debug("%s: Interface disc. or Sel. reset "
"(remote)\n", ch->id);
fsm_event(ch->fsm, CH_EVENT_UC_RCRESET, ch);
} else {
@@ -2034,7 +2029,6 @@ static void
dev_action_chup(fsm_instance * fi, int event, void *arg)
{
struct net_device *dev = (struct net_device *) arg;
- struct ctc_priv *privptr = dev->priv;
DBF_TEXT(trace, 3, __FUNCTION__);
switch (fsm_getstate(fi)) {
@@ -2049,8 +2043,6 @@ dev_action_chup(fsm_instance * fi, int e
fsm_newstate(fi, DEV_STATE_RUNNING);
ctc_pr_info("%s: connected with remote side\n",
dev->name);
- if (privptr->protocol == CTC_PROTO_LINUX_TTY)
- ctc_tty_setcarrier(dev, 1);
ctc_clear_busy(dev);
}
break;
@@ -2059,8 +2051,6 @@ dev_action_chup(fsm_instance * fi, int e
fsm_newstate(fi, DEV_STATE_RUNNING);
ctc_pr_info("%s: connected with remote side\n",
dev->name);
- if (privptr->protocol == CTC_PROTO_LINUX_TTY)
- ctc_tty_setcarrier(dev, 1);
ctc_clear_busy(dev);
}
break;
@@ -2086,14 +2076,10 @@ dev_action_chup(fsm_instance * fi, int e
static void
dev_action_chdown(fsm_instance * fi, int event, void *arg)
{
- struct net_device *dev = (struct net_device *) arg;
- struct ctc_priv *privptr = dev->priv;
DBF_TEXT(trace, 3, __FUNCTION__);
switch (fsm_getstate(fi)) {
case DEV_STATE_RUNNING:
- if (privptr->protocol == CTC_PROTO_LINUX_TTY)
- ctc_tty_setcarrier(dev, 0);
if (event == DEV_EVENT_TXDOWN)
fsm_newstate(fi, DEV_STATE_STARTWAIT_TX);
else
@@ -2397,8 +2383,6 @@ ctc_tx(struct sk_buff *skb, struct net_d
*/
if (fsm_getstate(privptr->fsm) != DEV_STATE_RUNNING) {
fsm_event(privptr->fsm, DEV_EVENT_START, dev);
- if (privptr->protocol == CTC_PROTO_LINUX_TTY)
- return -EBUSY;
dev_kfree_skb(skb);
privptr->stats.tx_dropped++;
privptr->stats.tx_errors++;
@@ -2608,20 +2592,13 @@ ctc_netdev_unregister(struct net_device
if (!dev)
return;
privptr = (struct ctc_priv *) dev->priv;
- if (privptr->protocol != CTC_PROTO_LINUX_TTY)
- unregister_netdev(dev);
- else
- ctc_tty_unregister_netdev(dev);
+ unregister_netdev(dev);
}
static int
ctc_netdev_register(struct net_device * dev)
{
- struct ctc_priv *privptr = (struct ctc_priv *) dev->priv;
- if (privptr->protocol != CTC_PROTO_LINUX_TTY)
- return register_netdev(dev);
- else
- return ctc_tty_register_netdev(dev);
+ return register_netdev(dev);
}
static void
@@ -2667,7 +2644,9 @@ ctc_proto_store(struct device *dev, stru
if (!priv)
return -ENODEV;
sscanf(buf, "%u", &value);
- if ((value < 0) || (value > CTC_PROTO_MAX))
+ if (!((value == CTC_PROTO_S390) ||
+ (value == CTC_PROTO_LINUX) ||
+ (value == CTC_PROTO_OS390)))
return -EINVAL;
priv->protocol = value;
@@ -2897,10 +2876,7 @@ ctc_new_device(struct ccwgroup_device *c
goto out;
}
- if (privptr->protocol == CTC_PROTO_LINUX_TTY)
- strlcpy(dev->name, "ctctty%d", IFNAMSIZ);
- else
- strlcpy(dev->name, "ctc%d", IFNAMSIZ);
+ strlcpy(dev->name, "ctc%d", IFNAMSIZ);
for (direction = READ; direction <= WRITE; direction++) {
privptr->channel[direction] =
@@ -3046,7 +3022,6 @@ ctc_exit(void)
{
DBF_TEXT(setup, 3, __FUNCTION__);
unregister_cu3088_discipline(&ctc_group_driver);
- ctc_tty_cleanup();
ctc_unregister_dbf_views();
ctc_pr_info("CTC driver unloaded\n");
}
@@ -3073,10 +3048,8 @@ ctc_init(void)
ctc_pr_crit("ctc_init failed with ctc_register_dbf_views rc = %d\n", ret);
return ret;
}
- ctc_tty_init();
ret = register_cu3088_discipline(&ctc_group_driver);
if (ret) {
- ctc_tty_cleanup();
ctc_unregister_dbf_views();
}
return ret;
diff --git a/drivers/s390/net/ctcmain.h b/drivers/s390/net/ctcmain.h
index d2e835c..7f305d1 100644
--- a/drivers/s390/net/ctcmain.h
+++ b/drivers/s390/net/ctcmain.h
@@ -35,7 +35,9 @@
#include <asm/ccwdev.h>
#include <asm/ccwgroup.h>
-#include "ctctty.h"
+#include <linux/skbuff.h>
+#include <linux/netdevice.h>
+
#include "fsm.h"
#include "cu3088.h"
@@ -50,9 +52,7 @@
#define CTC_PROTO_S390 0
#define CTC_PROTO_LINUX 1
-#define CTC_PROTO_LINUX_TTY 2
#define CTC_PROTO_OS390 3
-#define CTC_PROTO_MAX 3
#define CTC_BUFSIZE_LIMIT 65535
#define CTC_BUFSIZE_DEFAULT 32768
@@ -257,15 +257,13 @@ static __inline__ void
ctc_clear_busy(struct net_device * dev)
{
clear_bit(0, &(((struct ctc_priv *) dev->priv)->tbusy));
- if (((struct ctc_priv *)dev->priv)->protocol != CTC_PROTO_LINUX_TTY)
- netif_wake_queue(dev);
+ netif_wake_queue(dev);
}
static __inline__ int
ctc_test_and_set_busy(struct net_device * dev)
{
- if (((struct ctc_priv *)dev->priv)->protocol != CTC_PROTO_LINUX_TTY)
- netif_stop_queue(dev);
+ netif_stop_queue(dev);
return test_and_set_bit(0, &((struct ctc_priv *) dev->priv)->tbusy);
}
--
1.2.4
^ permalink raw reply related
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