* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 20:16 UTC (permalink / raw)
To: Sam Leffler
Cc: Johannes Berg, Jiri Benc, netdev, linux-kernel, John W. Linville
In-Reply-To: <43CBDF32.50109@errno.com>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
On Mon, Jan 16, 2006 at 10:00:18AM -0800, Sam Leffler wrote:
> Perhaps you haven't hit some of the more recent standards that place
> more of a burden on the ap implementation? Also some vendor-specific
> protocol features suck up space for ap mode only and it is nice to be
> able to include them only as needed.
While there is more work to be done on the AP side, and that code may
even be easily wrapped in an #ifdef, the majority of the complexity is
shared by both the station and the AP. It's worth mentioning that the
802.11 specs do not generally differentiate between "APs vs non-APs" --
they're all "STAs" of equal capabilities.
This is at least true of 802.11d, 802.11e, 802.11i
(supplicant/authenticator notwithstanding), 802.11j, and 802.11k. The
general difference is that the AP needs to be aware of the state of its
associated STAs, and perform different actions depending on configured
policy and the STAs' states, whereas the STAs generally do what the AP
tells them to do.
> There are several advantages to splitting up the code such as reduced
> audit complexity and real space savings but I agree that it is an open
> question whethere there's a big gain to modularizing the code by
> operating mode.
I agree that there would be some space savings, but they'd be relatively
small, at least if the stack is designed to be generic. This would make
the most difference for tiny/embedded systems -- but they'd want to use
#ifdefs to disable all AP code entirely, which includes all of the "if
(ap_mode) { } else { }" clauses that would litter the whole codebase,
regardless of modularity. (then if we use function pointers... that's a
*lot* of virtual functions..)
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
From: Andy Gospodarek @ 2006-01-16 20:25 UTC (permalink / raw)
To: Lee Revell; +Cc: linux-kernel, netdev, davem
In-Reply-To: <1137442446.19444.20.camel@mindpipe>
What userspace app will break because of this?
On 1/16/06, Lee Revell <rlrevell@joe-job.com> wrote:
> On Mon, 2006-01-16 at 15:04 -0500, Andy Gospodarek wrote:
> > Printing the total number of sockets used in /proc/net/sockstat is out
> > of place in a file that is supposed to contain information related to
> > ipv4 sockets. Removed output for total socket usage.
> >
>
> Um, you can't do that, it will break userspace.
>
> Lee
>
>
^ permalink raw reply
* Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
From: Jesper Juhl @ 2006-01-16 20:35 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Lee Revell, linux-kernel, netdev, davem
In-Reply-To: <bdfc5d6e0601161225h53554b1ahde794af93af52bdf@mail.gmail.com>
On 1/16/06, Andy Gospodarek <andy@greyhouse.net> wrote:
> What userspace app will break because of this?
>
> On 1/16/06, Lee Revell <rlrevell@joe-job.com> wrote:
> > On Mon, 2006-01-16 at 15:04 -0500, Andy Gospodarek wrote:
> > > Printing the total number of sockets used in /proc/net/sockstat is out
> > > of place in a file that is supposed to contain information related to
> > > ipv4 sockets. Removed output for total socket usage.
> > >
> >
> > Um, you can't do that, it will break userspace.
> >
That's not the point. The point is you can't go around changing things
exported to usersace - that has the potential to break apps. Even if
no app is known to the people on this list there may still be apps out
there depending on it - and we don't break userspace without *very*
good reasons, and even then it's announced for several months (years
sometimes) in Documentation/feature-removal.txt and elsewhere.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
From: Andy Gospodarek @ 2006-01-16 20:55 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Lee Revell, linux-kernel, netdev, davem
In-Reply-To: <9a8748490601161235k2defec82sa51a17e4fc14b22f@mail.gmail.com>
Jesper,
Thanks for the explanation. Your reasoning makes sense. I will
consider other ways to solve my current problem and post a patch that
doesn't "break userspace" if necessary.
-andy
On 1/16/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 1/16/06, Andy Gospodarek <andy@greyhouse.net> wrote:
> > What userspace app will break because of this?
> >
> > On 1/16/06, Lee Revell <rlrevell@joe-job.com> wrote:
> > > On Mon, 2006-01-16 at 15:04 -0500, Andy Gospodarek wrote:
> > > > Printing the total number of sockets used in /proc/net/sockstat is out
> > > > of place in a file that is supposed to contain information related to
> > > > ipv4 sockets. Removed output for total socket usage.
> > > >
> > >
> > > Um, you can't do that, it will break userspace.
> > >
>
> That's not the point. The point is you can't go around changing things
> exported to usersace - that has the potential to break apps. Even if
> no app is known to the people on this list there may still be apps out
> there depending on it - and we don't break userspace without *very*
> good reasons, and even then it's announced for several months (years
> sometimes) in Documentation/feature-removal.txt and elsewhere.
>
> --
> Jesper Juhl <jesper.juhl@gmail.com>
> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
> Plain text mails only, please http://www.expita.com/nomime.html
>
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 20:58 UTC (permalink / raw)
To: Sam Leffler; +Cc: Jeff Garzik, Johannes Berg, netdev, linux-kernel
In-Reply-To: <43CBFE90.8070208@errno.com>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
On Mon, Jan 16, 2006 at 12:14:08PM -0800, Sam Leffler wrote:
> Please read what I wrote again. Station mode power save work involves
> communicating with the ap and managing the hardware. The first
> interacts with bg scanning. We haven't even talked about how to handle
> sta mode power save.
I think we're arguing over semantics; what's important here is that the
STA tells the AP to buffer frames while we're performing a scan,
correct?
> If you wait until the end of the scan to return to the bss channel then
> you potentially miss buffered mcast frames. You can up the station's
> listen interval but that only gets you so far. As I said there are
> tradeoffs in doing this.
An excellent point. This is particularly relevant for APs that have a
DTIM interval of 1 -- if you're doing a passive scan, the dwell time on
that other channel (you need at least one beacon interval) could cause
you to miss bufferend MCAST frames.
In all fairness I don't think I've seen any implementations that handle
this cleanly.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-16 21:06 UTC (permalink / raw)
To: Samuel Ortiz
Cc: ext John W. Linville, Jeff Garzik, Johannes Berg, netdev,
linux-kernel
In-Reply-To: <Pine.LNX.4.58.0601162210550.17348@irie>
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
On Mon, Jan 16, 2006 at 10:16:06PM +0200, Samuel Ortiz wrote:
> Well, I'd rather trust a governement regulated network than my neighbour's
> AP ;-) In fact, some phones set their 802.11 regulatory domain based on
> the information they received from a somehow government regulated network,
> e.g. a GSM one.
The asumption is that 802.11d information, like current "regdomain"
settings, is fixed and not user-configurable. If the regdomain is
changeable by the user, that unit would not be approved for sale in that
particular locale.
(Now 802.11d doesn't specify what to do when you hear two conflicting
802.11d beacons.... there go those assumptions again..)
Stations respecting 802.11d rules are not allowed to transmit on any
supported frequency until they hear an AP on that frequency first.
This essentially means that all scans are passive until we hear an AP,
and we can't transmit on any other (presumably still silent) frequencies
unless we hear an 802.11d beacon that says we can.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
From: Jesper Juhl @ 2006-01-16 21:08 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Lee Revell, linux-kernel, netdev, davem
In-Reply-To: <bdfc5d6e0601161255w4e1a6ac5oaa6844a6e1bbd0aa@mail.gmail.com>
On 1/16/06, Andy Gospodarek <andy@greyhouse.net> wrote:
[could you *please* not top post? It's pretty annoying]
> Jesper,
>
> Thanks for the explanation. Your reasoning makes sense. I will
I'm glad you found it useful.
> consider other ways to solve my current problem and post a patch that
> doesn't "break userspace" if necessary.
>
Maybe if you described "your current problem" someone could suggest a
solution...
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Alan Cox @ 2006-01-16 22:24 UTC (permalink / raw)
To: John W. Linville
Cc: Samuel Ortiz, ext Stuffed Crust, Jeff Garzik, Johannes Berg,
netdev, linux-kernel
In-Reply-To: <20060116190629.GB5529@tuxdriver.com>
On Llu, 2006-01-16 at 14:06 -0500, John W. Linville wrote:
> If regulators come down on someone, it seems like common sense
> that they would be more lenient on mobile stations complying with a
> misconfigured AP than they would be with a mobile station ignoring a
> properly configured AP? I know expecting common sense from government
> regulators is optimistic, but still... :-)
I can't guess on the subject of US regulators but for the UK experience
in other communities (eg amateur radio), and public statements indicate
that their high priorities are interference with emergency services and
the like.
Concerns of direct relevance are
- transmitting on unlicensed frequencies (and 802.11 channel allocations
are dependant on nation - even within the EU)
- power violation
- anything else causing interference to other legitimate users at a
radio level
I would expect equipment to honour the subset of configurations that
meet BOTH the regulatory domain the system believes it exists within
(which may change dynamically!) AND the AP advertisement.
If I have told my equipment to obey UK law I expect it to do so. If I
hop on the train to France and forget to revise my configuration I'd
prefer it also believed the APs
Alan
^ permalink raw reply
* Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
From: Andy Gospodarek @ 2006-01-16 22:33 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Lee Revell, linux-kernel, netdev, davem
In-Reply-To: <9a8748490601161308g5f941c30o870042e6d9811c58@mail.gmail.com>
On 1/16/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> >
> Maybe if you described "your current problem" someone could suggest a
> solution...
>
Sure, I'd be glad to. If I add up all the entries from the procfiles
(in /proc/net) on my system
packet = 1
netlink = 6
raw = 0
raw6 = 0
tcp = 5
tcp6 = 3
udp = 9
udp6 = 1
unix = 29
I find there are a total of 54 sockets open on my system.
Now this seems to differ from the value in /proc/net/sockstat:
# cat sockstat
sockets: used 59
TCP: inuse 5 orphan 0 tw 0 alloc 8 mem 1
UDP: inuse 9
RAW: inuse 0
FRAG: inuse 0 memory 0
So we are off by 5. I added some code around the stat collection used
in sockstat to get more detailed info about those sockets and the
output is here. The values are family[protocol family][socket
family].
family[1][1] = 17 (UNIX/LOCAL,STREAM)
family[1][2] = 12 (UNIX/LOCAL,DGRAM)
family[2][1] = 5 (INET,STREAM)
family[2][2] = 9 (INET,DGRAM)
family[2][3] = 2 (INET,RAW)
family[10][1] = 3 (INET6,STREAM)
family[10][2] = 1 (INET6,DGRAM)
family[10][3] = 3 (INET6,RAW)
family[16][2] = 6 (NETLINK/ROUTE,DGRAM)
family[17][10] = 1 (PACKET,PACKET)
Total = 59
All of these numbers match up with what we saw above, except the
INET/RAW and INET6/RAW sockets. It seems they aren't being counted
correctly -- which accounts for the 5 missing sockets. The
decrementing of these values is in sock_release() and seems to get
done correctly other times RAW sockets are created, but not for the 5
sockets in question.
Since the total socket usage seems out of place in that file -- and
quite possibly wrong, it seemed like a nice idea to get rid of it
(prior to understanding the reasoning behind keeping it). Now it
seems the goal will be to fix the discrepancy between these files.
-andy
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: John W. Linville @ 2006-01-16 23:02 UTC (permalink / raw)
To: Alan Cox
Cc: Samuel Ortiz, ext Stuffed Crust, Jeff Garzik, Johannes Berg,
netdev, linux-kernel
In-Reply-To: <1137450281.15553.87.camel@localhost.localdomain>
On Mon, Jan 16, 2006 at 10:24:41PM +0000, Alan Cox wrote:
> I would expect equipment to honour the subset of configurations that
> meet BOTH the regulatory domain the system believes it exists within
> (which may change dynamically!) AND the AP advertisement.
>
> If I have told my equipment to obey UK law I expect it to do so. If I
> hop on the train to France and forget to revise my configuration I'd
> prefer it also believed the APs
Yes, this is an excellent point. I suppose this could result in
a non-functional configuration, but that is probably better than
conflicting w/ the local authorities... :-)
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* [PATCH 1/4 - 2.6.15 ]net : 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-16 23:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: YOSHIFUJI Hideaki / 吉藤英明, acme, ak,
linux-kernel, netdev, pereira.shaun
In-Reply-To: <200601161043.31742.arnd@arndb.de>
Hi
Here are the corrected patches
/Shaun
diff -uprN -X dontdiff linux-2.6.15-vanilla/include/linux/net.h
linux-2.6.15/include/linux/net.h
--- linux-2.6.15-vanilla/include/linux/net.h 2006-01-03
14:21:10.000000000 +1100
+++ linux-2.6.15/include/linux/net.h 2006-01-17 09:43:56.000000000 +1100
@@ -143,6 +143,8 @@ struct proto_ops {
struct poll_table_struct *wait);
int (*ioctl) (struct socket *sock, unsigned int cmd,
unsigned long arg);
+ int (*compat_ioctl) (struct socket *sock, unsigned int cmd,
+ unsigned long arg);
int (*listen) (struct socket *sock, int len);
int (*shutdown) (struct socket *sock, int flags);
int (*setsockopt)(struct socket *sock, int level,
@@ -247,6 +249,8 @@ SOCKCALL_UWRAP(name, poll, (struct file
(file, sock, wait)) \
SOCKCALL_WRAP(name, ioctl, (struct socket *sock, unsigned int cmd, \
unsigned long arg), (sock, cmd, arg)) \
+SOCKCALL_WRAP(name, compat_ioctl, (struct socket *sock, unsigned int
cmd, \
+ unsigned long arg), (sock, cmd, arg)) \
SOCKCALL_WRAP(name, listen, (struct socket *sock, int len), (sock,
len)) \
SOCKCALL_WRAP(name, shutdown, (struct socket *sock, int flags), (sock,
flags)) \
SOCKCALL_WRAP(name, setsockopt, (struct socket *sock, int level, int
optname, \
@@ -271,6 +275,7 @@ static struct proto_ops name##_ops = {
.getname = __lock_##name##_getname, \
.poll = __lock_##name##_poll, \
.ioctl = __lock_##name##_ioctl, \
+ .compat_ioctl = __lock_##name##_compat_ioctl, \
.listen = __lock_##name##_listen, \
.shutdown = __lock_##name##_shutdown, \
.setsockopt = __lock_##name##_setsockopt, \
@@ -279,6 +284,7 @@ static struct proto_ops name##_ops = {
.recvmsg = __lock_##name##_recvmsg, \
.mmap = __lock_##name##_mmap, \
};
+
#endif
#define MODULE_ALIAS_NETPROTO(proto) \
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/socket.c
linux-2.6.15/net/socket.c
--- linux-2.6.15-vanilla/net/socket.c 2006-01-03 14:21:10.000000000
+1100
+++ linux-2.6.15/net/socket.c 2006-01-17 09:43:56.000000000 +1100
@@ -109,6 +109,10 @@ static unsigned int sock_poll(struct fil
struct poll_table_struct *wait);
static long sock_ioctl(struct file *file,
unsigned int cmd, unsigned long arg);
+#ifdef CONFIG_COMPAT
+static long compat_sock_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg);
+#endif
static int sock_fasync(int fd, struct file *filp, int on);
static ssize_t sock_readv(struct file *file, const struct iovec
*vector,
unsigned long count, loff_t *ppos);
@@ -130,6 +134,9 @@ static struct file_operations socket_fil
.aio_write = sock_aio_write,
.poll = sock_poll,
.unlocked_ioctl = sock_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_sock_ioctl,
+#endif
.mmap = sock_mmap,
.open = sock_no_open, /* special open code to disallow open via /proc
*/
.release = sock_close,
@@ -2084,6 +2091,20 @@ void socket_seq_show(struct seq_file *se
}
#endif /* CONFIG_PROC_FS */
+#ifdef CONFIG_COMPAT
+static long compat_sock_ioctl(struct file *file, unsigned cmd, unsigned
long arg)
+{
+ struct socket *sock;
+ sock = file->private_data;
+
+ int ret = -ENOIOCTLCMD;
+ if(sock->ops->compat_ioctl)
+ ret = sock->ops->compat_ioctl(sock, cmd, arg);
+
+ return ret;
+}
+#endif
+
/* ABI emulation layers need these two */
EXPORT_SYMBOL(move_addr_to_kernel);
EXPORT_SYMBOL(move_addr_to_user);
^ permalink raw reply
* [PATCH 2/4 - 2.6.15]net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-16 23:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: YOSHIFUJI Hideaki / 吉藤英明, acme, ak,
linux-kernel, netdev, pereira.shaun
In-Reply-To: <200601161043.31742.arnd@arndb.de>
Provides a 32 bit conversion function for SIOCGSTAMP
diff -uprN -X dontdiff linux-2.6.15-vanilla/include/net/compat.h
linux-2.6.15/include/net/compat.h
--- linux-2.6.15-vanilla/include/net/compat.h 2006-01-03
14:21:10.000000000 +1100
+++ linux-2.6.15/include/net/compat.h 2006-01-17 09:52:50.000000000
+1100
@@ -23,6 +23,8 @@ struct compat_cmsghdr {
compat_int_t cmsg_type;
};
+extern int compat_sock_get_timestamp(struct sock *, struct timeval
__user *);
+
#else /* defined(CONFIG_COMPAT) */
#define compat_msghdr msghdr /* to avoid compiler warnings */
#endif /* defined(CONFIG_COMPAT) */
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/compat.c
linux-2.6.15/net/compat.c
--- linux-2.6.15-vanilla/net/compat.c 2006-01-03 14:21:10.000000000
+1100
+++ linux-2.6.15/net/compat.c 2006-01-17 09:52:50.000000000 +1100
@@ -503,6 +503,23 @@ static int do_get_sock_timeout(int fd, i
return err;
}
+int compat_sock_get_timestamp(struct sock *sk, struct timeval __user
*userstamp)
+{
+ struct compat_timeval __user *ctv
+ = (struct compat_timeval __user*) userstamp;
+ int err = -ENOENT;
+ if(!sock_flag(sk, SOCK_TIMESTAMP))
+ sock_enable_timestamp(sk);
+ if(sk->sk_stamp.tv_sec == -1)
+ return err;
+ if(sk->sk_stamp.tv_sec == 0)
+ do_gettimeofday(&sk->sk_stamp);
+ if (put_user(sk->sk_stamp.tv_sec, &ctv->tv_sec) |
+ put_user(sk->sk_stamp.tv_usec, &ctv->tv_usec))
+ err = -EFAULT;
+ return err;
+}
+
asmlinkage long compat_sys_getsockopt(int fd, int level, int optname,
char __user *optval, int __user *optlen)
{
@@ -602,3 +619,5 @@ asmlinkage long compat_sys_socketcall(in
}
return ret;
}
+
+EXPORT_SYMBOL(compat_sock_get_timestamp);
^ permalink raw reply
* [PATCH 3/4 -2.6.15]:x25: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-16 23:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: YOSHIFUJI Hideaki / 吉藤英明, acme, ak,
linux-kernel, netdev, pereira.shaun
In-Reply-To: <200601161043.31742.arnd@arndb.de>
Allows x25 to work in 32 bit mode on 64 bit kernel
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/x25/af_x25.c
linux-2.6.15/net/x25/af_x25.c
--- linux-2.6.15-vanilla/net/x25/af_x25.c 2006-01-03 14:21:10.000000000
+1100
+++ linux-2.6.15/net/x25/af_x25.c 2006-01-17 09:56:02.000000000 +1100
@@ -54,6 +54,8 @@
#include <linux/notifier.h>
#include <linux/init.h>
#include <net/x25.h>
+#include <linux/compat.h>
+#include <net/compat.h>
int sysctl_x25_restart_request_timeout = X25_DEFAULT_T20;
int sysctl_x25_call_request_timeout = X25_DEFAULT_T21;
@@ -68,6 +70,14 @@ static struct proto_ops x25_proto_ops;
static struct x25_address null_x25_address = {" "};
+#ifdef CONFIG_COMPAT
+struct compat_x25_subscrip_struct {
+ char device[200-sizeof(compat_ulong_t)];
+ compat_ulong_t global_facil_mask;
+ compat_uint_t extended;
+};
+#endif
+
int x25_addr_ntoa(unsigned char *p, struct x25_address *called_addr,
struct x25_address *calling_addr)
{
@@ -1391,6 +1401,119 @@ static struct net_proto_family x25_famil
.owner = THIS_MODULE,
};
+
+#ifdef CONFIG_COMPAT
+static int compat_x25_subscr_ioctl(unsigned int cmd,
+ struct compat_x25_subscrip_struct __user *x25_subscr32)
+{
+ struct x25_subscrip_struct x25_subscr;
+ struct x25_neigh *nb;
+ struct net_device *dev;
+ int rc = -EINVAL;
+
+ if (cmd != SIOCX25GSUBSCRIP && cmd != SIOCX25SSUBSCRIP)
+ goto out;
+
+ rc = -EFAULT;
+ if(copy_from_user(&x25_subscr, x25_subscr32, sizeof(*x25_subscr32)))
+ goto out;
+
+ rc = -EINVAL;
+ if ((dev = x25_dev_get(x25_subscr.device)) == NULL)
+ goto out;
+
+ if ((nb = x25_get_neigh(dev)) == NULL)
+ goto out_dev_put;
+
+ dev_put(dev);
+
+ if(cmd == SIOCX25GSUBSCRIP) {
+ x25_subscr.extended = nb->extended;
+ x25_subscr.global_facil_mask = nb->global_facil_mask;
+ rc = copy_to_user(x25_subscr32, &x25_subscr,
+ sizeof(*x25_subscr32)) ? -EFAULT : 0;
+ } else {
+ rc = -EINVAL;
+ if (!(x25_subscr.extended && x25_subscr.extended != 1)) {
+ rc = 0;
+ nb->extended = x25_subscr.extended;
+ nb->global_facil_mask = x25_subscr.global_facil_mask;
+ }
+ }
+ x25_neigh_put(nb);
+out:
+ return rc;
+out_dev_put:
+ dev_put(dev);
+ goto out;
+}
+
+static int compat_x25_ioctl(struct socket *sock, unsigned int cmd,
unsigned long arg)
+{
+ void __user *argp = compat_ptr(arg);
+ struct sock *sk = sock->sk;
+
+ int rc = -ENOIOCTLCMD;
+
+ switch(cmd) {
+ case TIOCOUTQ:
+ case TIOCINQ:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
+ case SIOCGSTAMP:
+ rc = -EINVAL;
+ if (sk)
+ rc = compat_sock_get_timestamp(sk,
+ (struct timeval __user*)argp);
+ break;
+ case SIOCGIFADDR:
+ case SIOCSIFADDR:
+ case SIOCGIFDSTADDR:
+ case SIOCSIFDSTADDR:
+ case SIOCGIFBRDADDR:
+ case SIOCSIFBRDADDR:
+ case SIOCGIFNETMASK:
+ case SIOCSIFNETMASK:
+ case SIOCGIFMETRIC:
+ case SIOCSIFMETRIC:
+ rc = -EINVAL;
+ break;
+ case SIOCADDRT:
+ case SIOCDELRT:
+ rc = -EPERM;
+ if(!capable(CAP_NET_ADMIN))
+ break;
+ rc = x25_route_ioctl(cmd, argp);
+ break;
+ case SIOCX25GSUBSCRIP:
+ rc = compat_x25_subscr_ioctl(cmd, argp);
+ break;
+ case SIOCX25SSUBSCRIP:
+ rc = -EPERM;
+ if (!capable(CAP_NET_ADMIN))
+ break;
+ rc = compat_x25_subscr_ioctl(cmd, argp);
+ break;
+ case SIOCX25GFACILITIES:
+ case SIOCX25SFACILITIES:
+ case SIOCX25GCALLUSERDATA:
+ case SIOCX25SCALLUSERDATA:
+ case SIOCX25GCAUSEDIAG:
+ case SIOCX25SCUDMATCHLEN:
+ case SIOCX25CALLACCPTAPPRV:
+ case SIOCX25SENDCALLACCPT:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
+ default:
+ rc = -ENOIOCTLCMD;
+ break;
+ }
+
+ return rc;
+}
+
+#endif
+
static struct proto_ops SOCKOPS_WRAPPED(x25_proto_ops) = {
.family = AF_X25,
.owner = THIS_MODULE,
@@ -1402,6 +1525,9 @@ static struct proto_ops SOCKOPS_WRAPPED(
.getname = x25_getname,
.poll = datagram_poll,
.ioctl = x25_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_x25_ioctl,
+#endif
.listen = x25_listen,
.shutdown = sock_no_shutdown,
.setsockopt = x25_setsockopt,
^ permalink raw reply
* [PATCH 4/4]x25: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-16 23:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: YOSHIFUJI Hideaki / 吉藤英明, acme, ak,
linux-kernel, netdev, pereira.shaun
In-Reply-To: <200601161043.31742.arnd@arndb.de>
A small fix for the following error, when trying to run a 64 bit x25
server application.
T2 kernel: schedule_timeout:
wrong timeout value ffffffffffffffff from ffffffff88164796
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/x25/af_x25.c
linux-2.6.15/net/x25/af_x25.c
--- linux-2.6.15-vanilla/net/x25/af_x25.c 2006-01-17 09:57:38.000000000
+1100
+++ linux-2.6.15/net/x25/af_x25.c 2006-01-17 09:58:04.000000000 +1100
@@ -747,7 +747,7 @@ out:
return rc;
}
-static int x25_wait_for_data(struct sock *sk, int timeout)
+static int x25_wait_for_data(struct sock *sk, long timeout)
{
DECLARE_WAITQUEUE(wait, current);
int rc = 0;
^ permalink raw reply
* Re: [PATCH 3/4 -2.6.15]:x25: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-17 0:15 UTC (permalink / raw)
To: spereira
Cc: YOSHIFUJI Hideaki / 吉藤英明, acme, ak,
linux-kernel, netdev, pereira.shaun
In-Reply-To: <1137453135.6553.19.camel@spereira05.tusc.com.au>
Am Dienstag, 17. Januar 2006 00:12 schrieb Shaun Pereira:
> +static int compat_x25_subscr_ioctl(unsigned int cmd,
> + struct compat_x25_subscrip_struct __user *x25_subscr32)
> +{
> + struct x25_subscrip_struct x25_subscr;
> + struct x25_neigh *nb;
> + struct net_device *dev;
> + int rc = -EINVAL;
> +
> + if (cmd != SIOCX25GSUBSCRIP && cmd != SIOCX25SSUBSCRIP)
> + goto out;
btw, the above check is not needed here, but that's not my point.
> +
> + rc = -EFAULT;
> + if(copy_from_user(&x25_subscr, x25_subscr32, sizeof(*x25_subscr32)))
> + goto out;
Unfortunately, I just found another bug in this code, similar to one you
already fixed in the sock_get_timestamp handler:
You can't do the copy_from_user like this if the arguments have different
types. Changing the declaration 'struct x25_subscrip_struct x25_subscr;'
to 'struct compat_x25_subscrip_struct x25_subscr;' should fix this problem,
but please verify that it really works with a test case that relies on the
contents of x25_subscr->extended.
Arnd <><
^ permalink raw reply
* Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-01-17 1:18 UTC (permalink / raw)
To: andy; +Cc: jesper.juhl, rlrevell, linux-kernel, netdev, davem, yoshfuji
In-Reply-To: <bdfc5d6e0601161433g1c51dd4dpbc5da4cd7581d5d6@mail.gmail.com>
In article <bdfc5d6e0601161433g1c51dd4dpbc5da4cd7581d5d6@mail.gmail.com> (at Mon, 16 Jan 2006 17:33:59 -0500), Andy Gospodarek <andy@greyhouse.net> says:
> On 1/16/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > >
> > Maybe if you described "your current problem" someone could suggest a
> > solution...
> >
>
> Sure, I'd be glad to. If I add up all the entries from the procfiles
> (in /proc/net) on my system
:
> I find there are a total of 54 sockets open on my system.
>
> Now this seems to differ from the value in /proc/net/sockstat:
> # cat sockstat
> sockets: used 59
:
> So we are off by 5. I added some code around the stat collection used
> in sockstat to get more detailed info about those sockets and the
> output is here. The values are family[protocol family][socket
> family].
:
> Total = 59
>
> All of these numbers match up with what we saw above, except the
> INET/RAW and INET6/RAW sockets. It seems they aren't being counted
> correctly -- which accounts for the 5 missing sockets. The
> decrementing of these values is in sock_release() and seems to get
> done correctly other times RAW sockets are created, but not for the 5
> sockets in question.
This is because we have several internal unhashed raw sockets in
kernel, which are not counted in the "raw" entry, but in "sockets."
--yoshfuji
^ permalink raw reply
* [PATCH 3/4 -2.6.15- RESEND]:x25: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-17 4:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: YOSHIFUJI Hideaki / 吉藤英明, acme, ak,
linux-kernel, netdev, pereira.shaun
In-Reply-To: <200601170115.07019.arnd@arndb.de>
Hi Arnd
Here is the corrected version.
Using the x25_subscrip_struct structure (extend value = 1) set
the following values in the kernel after copy_from_user
global facility mask is F00000000
Extended value is 1
Using the 32 bit compat_x25_subscrip_struct
set the following values in the struct after
copying from user.
global facility mask is 0000000F
Extended value is 1
The nb->global_facil_mask was then
set to 0000000F when extended was 1
Thanks for this,
/Shaun
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/x25/af_x25.c
linux-2.6.15/net/x25/af_x25.c
--- linux-2.6.15-vanilla/net/x25/af_x25.c 2006-01-03 14:21:10.000000000
+1100
+++ linux-2.6.15/net/x25/af_x25.c 2006-01-17 15:08:30.000000000 +1100
@@ -54,6 +54,8 @@
#include <linux/notifier.h>
#include <linux/init.h>
#include <net/x25.h>
+#include <linux/compat.h>
+#include <net/compat.h>
int sysctl_x25_restart_request_timeout = X25_DEFAULT_T20;
int sysctl_x25_call_request_timeout = X25_DEFAULT_T21;
@@ -68,6 +70,14 @@ static struct proto_ops x25_proto_ops;
static struct x25_address null_x25_address = {" "};
+#ifdef CONFIG_COMPAT
+struct compat_x25_subscrip_struct {
+ char device[200-sizeof(compat_ulong_t)];
+ compat_ulong_t global_facil_mask;
+ compat_uint_t extended;
+};
+#endif
+
int x25_addr_ntoa(unsigned char *p, struct x25_address *called_addr,
struct x25_address *calling_addr)
{
@@ -1391,6 +1401,116 @@ static struct net_proto_family x25_famil
.owner = THIS_MODULE,
};
+
+#ifdef CONFIG_COMPAT
+static int compat_x25_subscr_ioctl(unsigned int cmd,
+ struct compat_x25_subscrip_struct __user *x25_subscr32)
+{
+ struct compat_x25_subscrip_struct x25_subscr;
+ struct x25_neigh *nb;
+ struct net_device *dev;
+ int rc = -EINVAL;
+
+ rc = -EFAULT;
+ if(copy_from_user(&x25_subscr, x25_subscr32, sizeof(*x25_subscr32)))
+ goto out;
+
+ rc = -EINVAL;
+ if ((dev = x25_dev_get(x25_subscr.device)) == NULL)
+ goto out;
+
+ if ((nb = x25_get_neigh(dev)) == NULL)
+ goto out_dev_put;
+
+ dev_put(dev);
+
+ if(cmd == SIOCX25GSUBSCRIP) {
+ x25_subscr.extended = nb->extended;
+ x25_subscr.global_facil_mask = nb->global_facil_mask;
+ rc = copy_to_user(x25_subscr32, &x25_subscr,
+ sizeof(*x25_subscr32)) ? -EFAULT : 0;
+ } else {
+ rc = -EINVAL;
+ if (!(x25_subscr.extended && x25_subscr.extended != 1)) {
+ rc = 0;
+ nb->extended = x25_subscr.extended;
+ nb->global_facil_mask = x25_subscr.global_facil_mask;
+ }
+ }
+ x25_neigh_put(nb);
+out:
+ return rc;
+out_dev_put:
+ dev_put(dev);
+ goto out;
+}
+
+static int compat_x25_ioctl(struct socket *sock, unsigned int cmd,
unsigned long arg)
+{
+ void __user *argp = compat_ptr(arg);
+ struct sock *sk = sock->sk;
+
+ int rc = -ENOIOCTLCMD;
+
+ switch(cmd) {
+ case TIOCOUTQ:
+ case TIOCINQ:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
+ case SIOCGSTAMP:
+ rc = -EINVAL;
+ if (sk)
+ rc = compat_sock_get_timestamp(sk,
+ (struct timeval __user*)argp);
+ break;
+ case SIOCGIFADDR:
+ case SIOCSIFADDR:
+ case SIOCGIFDSTADDR:
+ case SIOCSIFDSTADDR:
+ case SIOCGIFBRDADDR:
+ case SIOCSIFBRDADDR:
+ case SIOCGIFNETMASK:
+ case SIOCSIFNETMASK:
+ case SIOCGIFMETRIC:
+ case SIOCSIFMETRIC:
+ rc = -EINVAL;
+ break;
+ case SIOCADDRT:
+ case SIOCDELRT:
+ rc = -EPERM;
+ if(!capable(CAP_NET_ADMIN))
+ break;
+ rc = x25_route_ioctl(cmd, argp);
+ break;
+ case SIOCX25GSUBSCRIP:
+ rc = compat_x25_subscr_ioctl(cmd, argp);
+ break;
+ case SIOCX25SSUBSCRIP:
+ rc = -EPERM;
+ if (!capable(CAP_NET_ADMIN))
+ break;
+ rc = compat_x25_subscr_ioctl(cmd, argp);
+ break;
+ case SIOCX25GFACILITIES:
+ case SIOCX25SFACILITIES:
+ case SIOCX25GCALLUSERDATA:
+ case SIOCX25SCALLUSERDATA:
+ case SIOCX25GCAUSEDIAG:
+ case SIOCX25SCUDMATCHLEN:
+ case SIOCX25CALLACCPTAPPRV:
+ case SIOCX25SENDCALLACCPT:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
+ default:
+ rc = -ENOIOCTLCMD;
+ break;
+ }
+
+ return rc;
+}
+
+#endif
+
static struct proto_ops SOCKOPS_WRAPPED(x25_proto_ops) = {
.family = AF_X25,
.owner = THIS_MODULE,
@@ -1402,6 +1522,9 @@ static struct proto_ops SOCKOPS_WRAPPED(
.getname = x25_getname,
.poll = datagram_poll,
.ioctl = x25_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_x25_ioctl,
+#endif
.listen = x25_listen,
.shutdown = sock_no_shutdown,
.setsockopt = x25_setsockopt,
^ permalink raw reply
* Re: [PATCH] fix ip[6]t_policy compiler warnings after x_tables merge
From: David S. Miller @ 2006-01-17 10:26 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20060114204052.GF6740@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Sat, 14 Jan 2006 21:40:53 +0100
> [NETFILTER] ip[6]t_policy: Fix compilation warnings
>
> ip[6]t_policy argument conversion slipped when merging with x_tables
>
> Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
> Signed-off-by: Harald Welte <laforge@netfilter.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH ] ethtool: Remove duplex info from CTRL register dump
From: Jeff Garzik @ 2006-01-17 13:08 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev, linux-kernel, John Ronciak, Jesse Brandeburg
In-Reply-To: <20060112071642.29428.23880.stgit@Gecko.tarbal.com>
Jeff Kirsher wrote:
> The duplex control register is used for setting the driver and is not
> necessary for debug purposes. The value of the duplex control register is
> what the register's current value is and may not reflect the correct status
> of te current connection. That is what the duplex status register is used
> for. To keep from confusing the user, we are removing the duplex register
> from the ethtool dump of the registers.
>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: John Ronciak <john.ronciak@intel.com>
applied, after replacing "ethtool:" with "e1000:" in the subject line.
Jeff
^ permalink raw reply
* Re: [2.6 patch] drivers/net/arcnet/: possible cleanups
From: Jeff Garzik @ 2006-01-17 13:38 UTC (permalink / raw)
To: Adrian Bunk; +Cc: akpm, linux-kernel, netdev
In-Reply-To: <20060114021022.GE29663@stusta.de>
Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - make needlessly global code static
> - arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null)
> - arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet)
>
> To make Jeff happy, arcnet.c still prints
> arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
applied
^ permalink raw reply
* Re: wireless: recap of current issues (stack)
From: Jean Tourrilhes @ 2006-01-17 17:38 UTC (permalink / raw)
To: Michael Buesch
Cc: Chase Venters, netdev, linux-kernel, Jiri Benc, Stefan Rompf,
Mike Kershaw, Krzysztof Halasa, Robert Hancock,
Alistair John Strachan, Dominik Brodowski, Denis Vlasenko,
Danny van Dyk, Stephen Hemminger, feyd, Andreas Mohr,
Bas Vermeulen, Jean Tourrilhes, Daniel Drake, Ulrich Kunitz,
Phil Dibowitz, Simon Kelley, Marcel Holtmann, Patrick McHardy,
Ingo Oeser, Harald
In-Reply-To: <200601141451.16232.mbuesch@freenet.de>
On Sat, Jan 14, 2006 at 02:51:14PM +0100, Michael Buesch wrote:
> On Saturday 14 January 2006 00:03, you wrote:
> > As an aside to this whole thing, I know we're talking about *kernel* wireless
> > but it's worthless to most people without good userland support as well.
> > Anyone have any thoughts and feelings on what things look like on the
> > desktop? I think if we work closely with some desktop people, we can shepard
> > in some wonderful new desktop support on top of the new netlink API.
>
> I am in the KDE development and have (almost) full access to the KDE svn
> repository. Altought I did not do much coding on KDE apps recently,
> I will be able to help in WiFi support for KDE.
> The first thing I thought of, was a tray icon with basic information
> about the available interfaces and basic configuration
> capabilities.
There is already at least 2 KDE applications for WiFi stuff,
and both are fully fledged (i.e. not just a signal meter) :
http://websvn.kde.org/trunk/KDE/kdenetwork/wifi/
http://websvn.kde.org/trunk/kdenonbeta/kifi/
Note that I've used neither, so I don't know how good they are
and what features are missing. If you decide to write another apps,
please send me the link so I can add it on my web page.
> Greetings Michael.
Have fun...
Jean
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-17 18:41 UTC (permalink / raw)
To: Alan Cox
Cc: John W. Linville, Samuel Ortiz, Jeff Garzik, Johannes Berg,
netdev, linux-kernel
In-Reply-To: <1137450281.15553.87.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
On Mon, Jan 16, 2006 at 10:24:41PM +0000, Alan Cox wrote:
> If I have told my equipment to obey UK law I expect it to do so. If I
> hop on the train to France and forget to revise my configuration I'd
> prefer it also believed the APs
It's not that you might forget to revise your configuration, but that
the vast majority of users will not revise anything, and still expect
things to "just work". Kind of like multi-band cell phones.
This isn't that big of a deal in the 2.4GHz band, but when you start
talking about 5GHz, especially in France, things get a lot trickier.
Of course, all of this automagic "just work" crap only affects the STAs.
For AP operation, we have to trust the user to set the correct locale --
I don't see any way of including a sane "just-works" default in the
stock kernel.org tree, so I think the default should be be "none". This
way the user is forced to explicitly set the regdomain in order for the
AP startup to succeed.
...and pray that the AP isn't migrating to a different regdomain, but
there's really nothing anyone can do about that.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Adrian Bunk @ 2006-01-17 18:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Vitaly Bordug, jgarzik, saw, linux-kernel, netdev
In-Reply-To: <20060115160340.6f8cc7d6@localhost.localdomain>
On Sun, Jan 15, 2006 at 04:03:40PM -0800, Stephen Hemminger wrote:
> On Sun, 15 Jan 2006 16:19:58 +0300
> Vitaly Bordug <vbordug@ru.mvista.com> wrote:
>
> > On Thu, 5 Jan 2006 19:18:26 +0100
> > Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > This patch removes the obsolete drivers/net/eepro100.c driver.
> > >
> > > Is there any known problem in e100 still preventing us from removing
> > > this driver (it seems noone was able anymore to verify the ARM problem)?
> > >
> > I think I am recalling some problems on ppc82xx, when e100 was stuck on startup,
> > and eepro100 worked just fine.
> >
> > Even if the patch below will be scheduled for application, we need to set up enough time
> > for approval that e100 will be fine for all the up-to-date hw; or it should be fixed/updated before eepro100 removal.
> >
> > >
> > > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> > >
> > >
>
> How about doing what was done with devfs removal, and remove it
> from the config menu system for a couple of releases.
IMHO the devfs case was different since the complete devfs removal patch
(although being straightforward) touches many files.
In the eepro100 case (assuming there were no more known regressions in
the e100 driver), reverting the removal patch would be trivial.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Kyle Moffett @ 2006-01-17 18:54 UTC (permalink / raw)
To: Stuffed Crust
Cc: Alan Cox, John W. Linville, Samuel Ortiz, Jeff Garzik,
Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060117184114.GB20298@shaftnet.org>
On Jan 17, 2006, at 13:41, Stuffed Crust wrote:
> On Mon, Jan 16, 2006 at 10:24:41PM +0000, Alan Cox wrote:
>> If I have told my equipment to obey UK law I expect it to do so.
>> If I hop on the train to France and forget to revise my
>> configuration I'd prefer it also believed the APs
>
> It's not that you might forget to revise your configuration, but
> that the vast majority of users will not revise anything, and still
> expect things to "just work". Kind of like multi-band cell phones.
Alan's point is still very valid. From a poweruser point of view, if
I specifically tell my wireless client "You must obey US laws", and
then I wander over past a broken imported AP, I don't want my client
to _expand_ its allowable range. IMHO, userspace should be able to
forcibly restrict wireless frequencies to a certain regdomain (or
leave unrestricted and passive-scan-only), and specify how AP/
configured regdomains act. Given the range of possibilities, I think
that a userspace daemon monitoring events and dynamically configuring
the useable frequencies would best. That way the userspace daemon
could be configured to ignore APs, union/intersect the APs with the
configured regdomain, ignore the configured regdomain in the presence
of APs, etc.
Cheers,
Kyle Moffett
--
I lost interest in "blade servers" when I found they didn't throw
knives at people who weren't supposed to be in your machine room.
-- Anthony de Boer
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stefan Rompf @ 2006-01-17 22:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: Sam Leffler, netdev, linux-kernel
In-Reply-To: <1137355912.2520.97.camel@localhost>
Am Sonntag 15 Januar 2006 21:11 schrieb Johannes Berg:
> [iwconfig mode ...]
>
> Yeah, I agree with this, it is much cleaner to handle in the kernel.
> Think about the issues if you have a struct net_device that has 250
> bytes of "payload" for the struct virtual_sta_device in it and you want
> to switch that to a struct virtual_monitor_device. Icky.
Well, nobody forces you to allocate dev->priv together with the net_device,
you can set and change this pointer yourself. So I don't see a problem here.
Stefan
^ 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