* [PATCH v3 1/3] iproute2: add support for setting device groups
From: Vlad Dogaru @ 2011-01-26 16:41 UTC (permalink / raw)
To: netdev; +Cc: Vlad Dogaru, Stephen Hemminger
In-Reply-To: <1296060086-18777-1-git-send-email-ddvlad@rosedu.org>
Use the group keyword to specify what group the device should belong to.
Since the kernel uses numbers internally, mapping of group names to
numbers is defined in /etc/iproute2/group_map. Example usage:
ip link set dev eth0 group default
Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
---
etc/iproute2/group_map | 2 ++
include/linux/if_link.h | 1 +
include/utils.h | 2 ++
ip/ip_common.h | 2 ++
ip/iplink.c | 9 +++++++++
lib/utils.c | 41 +++++++++++++++++++++++++++++++++++++++++
man/man8/ip.8 | 9 +++++++++
tc/m_ematch.c | 39 ---------------------------------------
8 files changed, 66 insertions(+), 39 deletions(-)
create mode 100644 etc/iproute2/group_map
diff --git a/etc/iproute2/group_map b/etc/iproute2/group_map
new file mode 100644
index 0000000..6f000b2
--- /dev/null
+++ b/etc/iproute2/group_map
@@ -0,0 +1,2 @@
+# device group names
+0 default
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index e87456c..54d05f9 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -135,6 +135,7 @@ enum {
IFLA_VF_PORTS,
IFLA_PORT_SELF,
IFLA_AF_SPEC,
+ IFLA_GROUP,
__IFLA_MAX
};
diff --git a/include/utils.h b/include/utils.h
index 3da6998..327373e 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -152,4 +152,6 @@ extern int makeargs(char *line, char *argv[], int maxargs);
struct iplink_req;
int iplink_parse(int argc, char **argv, struct iplink_req *req,
char **name, char **type, char **link, char **dev);
+
+int lookup_map_id(const char *kind, int *dst, const char *file);
#endif /* __UTILS_H__ */
diff --git a/ip/ip_common.h b/ip/ip_common.h
index a114186..b751d46 100644
--- a/ip/ip_common.h
+++ b/ip/ip_common.h
@@ -68,3 +68,5 @@ struct link_util *get_link_kind(const char *kind);
#ifndef INFINITY_LIFE_TIME
#define INFINITY_LIFE_TIME 0xFFFFFFFFU
#endif
+
+#define GROUP_MAP "/etc/iproute2/group_map"
diff --git a/ip/iplink.c b/ip/iplink.c
index cb2c4f5..6c9df43 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -68,6 +68,7 @@ void iplink_usage(void)
fprintf(stderr, " [ mtu MTU ]\n");
fprintf(stderr, " [ netns PID ]\n");
fprintf(stderr, " [ alias NAME ]\n");
+ fprintf(stderr, " [ group GROUP ]\n");
fprintf(stderr, " [ vf NUM [ mac LLADDR ]\n");
fprintf(stderr, " [ vlan VLANID [ qos VLAN-QOS ] ]\n");
fprintf(stderr, " [ rate TXRATE ] ] \n");
@@ -252,6 +253,7 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
int mtu = -1;
int netns = -1;
int vf = -1;
+ int group = -1;
ret = argc;
@@ -297,6 +299,13 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
if (get_integer(&mtu, *argv, 0))
invarg("Invalid \"mtu\" value\n", *argv);
addattr_l(&req->n, sizeof(*req), IFLA_MTU, &mtu, 4);
+ } else if (strcmp(*argv, "group") == 0) {
+ NEXT_ARG();
+ if (group != -1)
+ duparg("group", *argv);
+ if (lookup_map_id(*argv, &group, GROUP_MAP))
+ invarg("Invalid \"group\" value\n", *argv);
+ addattr_l(&req->n, sizeof(*req), IFLA_GROUP, &group, 4);
} else if (strcmp(*argv, "netns") == 0) {
NEXT_ARG();
if (netns != -1)
diff --git a/lib/utils.c b/lib/utils.c
index a60d884..3642cb7 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -25,6 +25,7 @@
#include <linux/pkt_sched.h>
#include <time.h>
#include <sys/time.h>
+#include <errno.h>
#include "utils.h"
@@ -760,3 +761,43 @@ int makeargs(char *line, char *argv[], int maxargs)
return argc;
}
+
+int lookup_map_id(const char *kind, int *dst, const char *file)
+{
+ int err = -EINVAL;
+ char buf[512];
+ FILE *fd = fopen(file, "r");
+
+ if (fd == NULL) {
+ fprintf(stderr, "open %s: %s\n", file, strerror(errno));
+ return -errno;
+ }
+
+ while (fgets(buf, sizeof(buf), fd)) {
+ char namebuf[512], *p = buf;
+ int id;
+
+ while (*p == ' ' || *p == '\t')
+ p++;
+ if (*p == '#' || *p == '\n' || *p == 0)
+ continue;
+
+ if (sscanf(p, "%d %s", &id, namebuf) != 2) {
+ fprintf(stderr, "map %s corrupted at %s\n",
+ file, p);
+ goto out;
+ }
+
+ if (!strcasecmp(namebuf, kind)) {
+ if (dst)
+ *dst = id;
+ err = 0;
+ goto out;
+ }
+ }
+
+ err = -ENOENT;
+out:
+ fclose(fd);
+ return err;
+}
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 8d55fa9..77e03d8 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -86,6 +86,9 @@ ip \- show / manipulate routing, devices, policy routing and tunnels
.B alias
.IR NAME " |"
.br
+.B group
+.IR GROUP " |"
+.br
.B vf
.IR NUM " ["
.B mac
@@ -994,6 +997,12 @@ move the device to the network namespace associated with the process
give the device a symbolic name for easy reference.
.TP
+.BI group " GROUP"
+specify the group the device belongs to.
+The available groups are listed in file
+.BR "/etc/iproute2/group_map" .
+
+.TP
.BI vf " NUM"
specify a Virtual Function device to be configured. The associated PF device
must be specified using the
diff --git a/tc/m_ematch.c b/tc/m_ematch.c
index 4c3acf8..4a6855c 100644
--- a/tc/m_ematch.c
+++ b/tc/m_ematch.c
@@ -87,45 +87,6 @@ out:
return err;
}
-static int lookup_map_id(char *kind, int *dst, const char *file)
-{
- int err = -EINVAL;
- char buf[512];
- FILE *fd = fopen(file, "r");
-
- if (fd == NULL)
- return -errno;
-
- while (fgets(buf, sizeof(buf), fd)) {
- char namebuf[512], *p = buf;
- int id;
-
- while (*p == ' ' || *p == '\t')
- p++;
- if (*p == '#' || *p == '\n' || *p == 0)
- continue;
-
- if (sscanf(p, "%d %s", &id, namebuf) != 2) {
- fprintf(stderr, "ematch map %s corrupted at %s\n",
- file, p);
- goto out;
- }
-
- if (!strcasecmp(namebuf, kind)) {
- if (dst)
- *dst = id;
- err = 0;
- goto out;
- }
- }
-
- err = -ENOENT;
- *dst = 0;
-out:
- fclose(fd);
- return err;
-}
-
static struct ematch_util *get_ematch_kind(char *kind)
{
static void *body;
--
1.7.1
^ permalink raw reply related
* [PATCH v3 3/3] iproute2: support setting device parameters by group
From: Vlad Dogaru @ 2011-01-26 16:41 UTC (permalink / raw)
To: netdev; +Cc: Vlad Dogaru, Stephen Hemminger
In-Reply-To: <1296060086-18777-1-git-send-email-ddvlad@rosedu.org>
Users can now modify basic device parameters with a single call. We use
the devgroup keyword to specify the device group to work on. For
instance, to take down all interfaces in group `default':
ip link set down devgroup default
Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
---
include/utils.h | 3 ++-
ip/iplink.c | 48 +++++++++++++++++++++++++++++++++++++++++++++---
ip/link_veth.c | 3 ++-
man/man8/ip.8 | 11 +++++++++--
4 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/include/utils.h b/include/utils.h
index 327373e..c708b74 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -151,7 +151,8 @@ extern int makeargs(char *line, char *argv[], int maxargs);
struct iplink_req;
int iplink_parse(int argc, char **argv, struct iplink_req *req,
- char **name, char **type, char **link, char **dev);
+ char **name, char **type, char **link, char **dev,
+ int *devgroup);
int lookup_map_id(const char *kind, int *dst, const char *file);
#endif /* __UTILS_H__ */
diff --git a/ip/iplink.c b/ip/iplink.c
index a781848..85d2efa 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -51,7 +51,7 @@ void iplink_usage(void)
fprintf(stderr, " type TYPE [ ARGS ]\n");
fprintf(stderr, " ip link delete DEV type TYPE [ ARGS ]\n");
fprintf(stderr, "\n");
- fprintf(stderr, " ip link set DEVICE [ { up | down } ]\n");
+ fprintf(stderr, " ip link set { dev DEVICE | devgroup DEVGROUP } [ { up | down } ]\n");
} else
fprintf(stderr, "Usage: ip link set DEVICE [ { up | down } ]\n");
@@ -246,7 +246,8 @@ int iplink_parse_vf(int vf, int *argcp, char ***argvp,
int iplink_parse(int argc, char **argv, struct iplink_req *req,
- char **name, char **type, char **link, char **dev)
+ char **name, char **type, char **link, char **dev,
+ int *devgroup)
{
int ret, len;
char abuf[32];
@@ -257,6 +258,7 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
int group = -1;
ret = argc;
+ *devgroup = -1; /* Not set. */
while (argc > 0) {
if (strcmp(*argv, "up") == 0) {
@@ -396,6 +398,20 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
} else {
if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
+ if (*dev)
+ duparg2("dev", *argv);
+ *dev = *argv;
+ argc--; argv++;
+ continue;
+ }
+ if (matches(*argv, "devgroup") == 0) {
+ NEXT_ARG();
+ if (*devgroup != -1)
+ duparg("devgroup", *argv);
+ if (lookup_map_id(*argv, devgroup, GROUP_MAP))
+ invarg("Invalid \"devgroup\" value\n", *argv);
+ argc--; argv++;
+ continue;
}
if (matches(*argv, "help") == 0)
usage();
@@ -406,6 +422,11 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
argc--; argv++;
}
+ if (*dev && (*devgroup != -1)) {
+ fprintf(stderr, "dev and devgroup cannot be both be present.\n");
+ exit(-1);
+ }
+
return ret - argc;
}
@@ -416,6 +437,7 @@ static int iplink_modify(int cmd, unsigned int flags, int argc, char **argv)
char *name = NULL;
char *link = NULL;
char *type = NULL;
+ int devgroup;
struct link_util *lu = NULL;
struct iplink_req req;
int ret;
@@ -427,12 +449,32 @@ static int iplink_modify(int cmd, unsigned int flags, int argc, char **argv)
req.n.nlmsg_type = cmd;
req.i.ifi_family = preferred_family;
- ret = iplink_parse(argc, argv, &req, &name, &type, &link, &dev);
+ ret = iplink_parse(argc, argv, &req, &name, &type, &link, &dev, &devgroup);
if (ret < 0)
return ret;
argc -= ret;
argv += ret;
+
+ if (devgroup != -1) {
+ if (argc) {
+ fprintf(stderr, "Garbage instead of arguments \"%s ...\". "
+ "Try \"ip link help\".\n", *argv);
+ return -1;
+ }
+ if (flags & NLM_F_CREATE) {
+ fprintf(stderr, "devgroup cannot be used when "
+ "creating devices.\n");
+ return -1;
+ }
+
+ req.i.ifi_index = 0;
+ addattr32(&req.n, sizeof(req), IFLA_GROUP, devgroup);
+ if (rtnl_talk(&rth, &req.n, 0, 0, NULL, NULL, NULL) < 0)
+ exit(2);
+ return 0;
+ }
+
ll_init_map(&rth);
if (type) {
diff --git a/ip/link_veth.c b/ip/link_veth.c
index 9f5e871..06974e7 100644
--- a/ip/link_veth.c
+++ b/ip/link_veth.c
@@ -30,6 +30,7 @@ static int veth_parse_opt(struct link_util *lu, int argc, char **argv,
char *name, *type, *link, *dev;
int err, len;
struct rtattr * data;
+ int devgroup;
if (strcmp(argv[0], "peer") != 0) {
usage();
@@ -42,7 +43,7 @@ static int veth_parse_opt(struct link_util *lu, int argc, char **argv,
hdr->nlmsg_len += sizeof(struct ifinfomsg);
err = iplink_parse(argc - 1, argv + 1, (struct iplink_req *)hdr,
- &name, &type, &link, &dev);
+ &name, &type, &link, &dev, &devgroup);
if (err < 0)
return err;
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 5c42156..302523a 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -55,8 +55,10 @@ ip \- show / manipulate routing, devices, policy routing and tunnels
.RI "[ " ARGS " ]"
.ti -8
-.BI "ip link set " DEVICE
-.RB "{ " up " | " down " | " arp " { " on " | " off " } |"
+.BR "ip link set " {
+.IR DEVICE " | "
+.BI "devgroup " DEVGROUP
+.RB "} { " up " | " down " | " arp " { " on " | " off " } |"
.br
.BR promisc " { " on " | " off " } |"
.br
@@ -933,6 +935,11 @@ specifies network device to operate on. When configuring SR-IOV Virtual Fuction
device.
.TP
+.BI devgroup " DEVGROUP "
+.I DEVGROUP
+specifies network device group to operate on.
+
+.TP
.BR up " and " down
change the state of the device to
.B UP
--
1.7.1
^ permalink raw reply related
* [PATCH v3 2/3] iproute2: support listing devices by group
From: Vlad Dogaru @ 2011-01-26 16:41 UTC (permalink / raw)
To: netdev; +Cc: Vlad Dogaru, Stephen Hemminger
In-Reply-To: <1296060086-18777-1-git-send-email-ddvlad@rosedu.org>
User can specify device group to list by using the devgroup keyword:
ip link lst devgroup test
If no group is specified, 0 (default) is implied.
Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
---
include/linux/netdevice.h | 2 +-
ip/ipaddress.c | 14 ++++++++++++++
ip/iplink.c | 3 ++-
man/man8/ip.8 | 11 +++++++++--
4 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index bec4e23..ad2e34d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -33,7 +33,7 @@
#define MAX_ADDR_LEN 32 /* Largest hardware address length */
-
+#define INIT_NETDEV_GROUP 0 /* Initial group net devices belong to */
/* Media selection options. */
enum {
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index a775ecd..c634391 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -49,6 +49,7 @@ static struct
char *flushb;
int flushp;
int flushe;
+ int group;
} filter;
static int do_link;
@@ -246,6 +247,12 @@ int print_linkinfo(const struct sockaddr_nl *who,
fnmatch(filter.label, RTA_DATA(tb[IFLA_IFNAME]), 0))
return 0;
+ if (tb[IFLA_GROUP]) {
+ int group = *(int*)RTA_DATA(tb[IFLA_GROUP]);
+ if (group != filter.group)
+ return -1;
+ }
+
if (n->nlmsg_type == RTM_DELLINK)
fprintf(fp, "Deleted ");
@@ -718,9 +725,12 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
if (filter.family == AF_UNSPEC)
filter.family = preferred_family;
+ filter.group = INIT_NETDEV_GROUP;
+
if (flush) {
if (argc <= 0) {
fprintf(stderr, "Flush requires arguments.\n");
+
return -1;
}
if (filter.family == AF_PACKET) {
@@ -779,6 +789,10 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
} else if (strcmp(*argv, "label") == 0) {
NEXT_ARG();
filter.label = *argv;
+ } else if (strcmp(*argv, "devgroup") == 0) {
+ NEXT_ARG();
+ if (lookup_map_id(*argv, &filter.group, GROUP_MAP))
+ invarg("Invalid \"group\" value\n", *argv);
} else {
if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
diff --git a/ip/iplink.c b/ip/iplink.c
index 6c9df43..a781848 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -66,13 +66,14 @@ void iplink_usage(void)
fprintf(stderr, " [ address LLADDR ]\n");
fprintf(stderr, " [ broadcast LLADDR ]\n");
fprintf(stderr, " [ mtu MTU ]\n");
+ fprintf(stderr, " [ group GROUP ]\n");
fprintf(stderr, " [ netns PID ]\n");
fprintf(stderr, " [ alias NAME ]\n");
fprintf(stderr, " [ group GROUP ]\n");
fprintf(stderr, " [ vf NUM [ mac LLADDR ]\n");
fprintf(stderr, " [ vlan VLANID [ qos VLAN-QOS ] ]\n");
fprintf(stderr, " [ rate TXRATE ] ] \n");
- fprintf(stderr, " ip link show [ DEVICE ]\n");
+ fprintf(stderr, " ip link show [ DEVICE | devgroup DEVGROUP ]\n");
if (iplink_have_newlink()) {
fprintf(stderr, "\n");
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 77e03d8..5c42156 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -102,7 +102,9 @@ ip \- show / manipulate routing, devices, policy routing and tunnels
.ti -8
.B ip link show
-.RI "[ " DEVICE " ]"
+.RI "[ " DEVICE " | "
+.B devgroup
+.IR GROUP " ]"
.ti -8
.BR "ip addr" " { " add " | " del " } "
@@ -1065,7 +1067,12 @@ call.
.BI dev " NAME " (default)
.I NAME
specifies the network device to show.
-If this argument is omitted all devices are listed.
+If this argument is omitted all devices in the default group are listed.
+
+.TP
+.BI devgroup " GROUP "
+.I GROUP
+specifies what group of devices to show.
.TP
.B up
--
1.7.1
^ permalink raw reply related
* [PATCH v3 0/3] iproute2: support for device groups
From: Vlad Dogaru @ 2011-01-26 16:41 UTC (permalink / raw)
To: netdev; +Cc: Vlad Dogaru, Stephen Hemminger
This patch series adds userspace support for network device groups.
There is support for setting device groups, listing only interfaces of a
specific group, and setting basic device parameters for all interfaces
in a group.
Changes since version 2:
* groups now have names. The mapping between names and numbers (which
are used by the kernel) is in /etc/iproute2/group_map.
* the ip man page and usage display function have been updated to
reflect the new functionality.
Changes since version 1:
* a single attribute is used for both setting the group of a device and
manipulating an entire group.
Vlad Dogaru (3):
iproute2: add support for setting device groups
iproute2: support listing devices by group
iproute2: support setting device parameters by group
etc/iproute2/group_map | 2 +
include/linux/if_link.h | 1 +
include/linux/netdevice.h | 2 +-
include/utils.h | 5 +++-
ip/ip_common.h | 2 +
ip/ipaddress.c | 14 ++++++++++
ip/iplink.c | 60 ++++++++++++++++++++++++++++++++++++++++++---
ip/link_veth.c | 3 +-
lib/utils.c | 41 ++++++++++++++++++++++++++++++
man/man8/ip.8 | 31 ++++++++++++++++++++---
tc/m_ematch.c | 39 -----------------------------
11 files changed, 150 insertions(+), 50 deletions(-)
create mode 100644 etc/iproute2/group_map
^ permalink raw reply
* RE: [RFC 00/20] Proposal for remaining BKL users
From: Palash Bandyopadhyay @ 2011-01-26 16:24 UTC (permalink / raw)
To: Arnd Bergmann, Mauro Carvalho Chehab
Cc: Frederic Weisbecker, dri-devel@lists.freedesktop.org,
Mikulas Patocka, H. Peter Anvin, Ian Kent,
linux-cifs@vger.kernel.org, Nick Bowler,
linux-x25@vger.kernel.org, Takahiro Hirofuchi, Ross Cohen,
Arnaldo Carvalho de Melo, Evgeniy Dushistov, Stuart Swales,
Thomas Gleixner, Arjan van de Ven, autofs@linux.kernel.org,
Jeff Layton, netdev@vger.kernel.org, Greg KH,
"linux-kernel@vger.ker
In-Reply-To: <201101261445.17751.arnd@arndb.de>
I think it should be ok. If we do hit any performance issue, we'll revisit this.
Thanks,
Palash
-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de]
Sent: Wednesday, January 26, 2011 5:45 AM
To: Mauro Carvalho Chehab
Cc: Greg KH; linux-kernel@vger.kernel.org; Andrew Hendry; Andrew Morton; Arjan van de Ven; Arnaldo Carvalho de Melo; autofs@linux.kernel.org; Chris Wilson; Dave Airlie; dri-devel@lists.freedesktop.org; Evgeniy Dushistov; Frederic Weisbecker; H. Peter Anvin; Ian Kent; Ingo Molnar; Jeff Layton; linux-cifs@vger.kernel.org; linux-fsdevel@vger.kernel.org; linux-x25@vger.kernel.org; Mikulas Patocka; netdev@vger.kernel.org; Nick Bowler; Palash Bandyopadhyay; Ross Cohen; Russell King; Stuart Swales; Takahiro Hirofuchi; Thomas Gleixner
Subject: Re: [RFC 00/20] Proposal for remaining BKL users
On Wednesday 26 January 2011, Mauro Carvalho Chehab wrote:
> I guess you're meaning cx25821, right?
Right, sorry for the typo.
> Palash should take a look on it and review. This is a device that allows
> 12 simultaneous streams, so, I suspect that he'll need to do some
> changes at the locking schema, to avoid performance bottlenecks.
I would be surprised if there was any measurable performance change.
The BKL was used only in the open() function to iterate the device
list, and that code is nowhere on a critical path, as far as I can tell.
Arnd
Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
---------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] fix validate_link_af in rtnetlink core
From: Patrick McHardy @ 2011-01-26 15:36 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: netdev
In-Reply-To: <20110126145523.GA3171@e-circ.dyndns.org>
On 26.01.2011 15:55, Kurt Van Dijck wrote:
> Hi,
>
> I'm not sure about this patch.
>
> I'm testing an API that uses IFLA_AF_SPEC attribute.
> In the rtnetlink core , the set_link_af() member
> of the rtnl_af_ops struct receives the nested attribute
> (as I expected), but the validate_link_af() member
> receives the parent attribute.
> IMO, this patch fixes this.
>
> Since I didn't find any code in iproute2 that makes use
> of this attribute, I wasn't able to verify this on the userspace
> end.
There's code in libnl using this, your patch looks fine to me.
^ permalink raw reply
* Re: [PATCH v4] smc91x: add devicetree support
From: Grant Likely @ 2011-01-26 15:32 UTC (permalink / raw)
To: Nicolas Pitre
Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, lkml, David Miller
In-Reply-To: <alpine.LFD.2.00.1101261004560.8580-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
On Wed, Jan 26, 2011 at 8:17 AM, Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org> wrote:
> On Wed, 26 Jan 2011, Thomas Chou wrote:
>
>> Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
>> ---
>> v2 specify part numbers in compat as Grant suggested.
>> v3 more specific part name.
>> v4 include match table only for OF as David suggested.
>
> The smc91x driver relies on many parameters which are platform specific,
> such as the bus width capabilities, register spacing due to special bus
> wiring, interrupt signal level, LED configuration, whether or not to
> configure the chip with a wait state, etc. Will the device tree support
> take care of those things?
Short answer, yes
In general bindings are written and documented as they are needed. In
this specific case,yes the device configuration should be encoded into
the device tree node. It is okay for now to not wire up any of that
configuration if the defaults work for Thomas' platform, but to be
useful in the long run they do need to be added.
Typically a block or function call is added to the drivers .probe hook
to decode device tree data if the of_node pointer is set.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] IPVS changes for 2.6.38-rc3
From: Patrick McHardy @ 2011-01-26 15:27 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netfilter-devel, netdev, Changli Gao, Julian Anastasov
In-Reply-To: <20110125235744.GA11026@verge.net.au>
On 26.01.2011 00:57, Simon Horman wrote:
> On Tue, Jan 25, 2011 at 03:01:35PM +0100, Patrick McHardy wrote:
>> On 25.01.2011 14:17, Simon Horman wrote:
>>> Hi Patrick,
>>>
>>> please consider pulling
>>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git for-patrick
>>>
>>> Which includes the following changes, both of which I believe 2.6.38 material.
>>>
>>> Changli Gao (1):
>>> netfilter: ipvs: fix compiler warnings
>>>
>>> Hans Schillstrom (1):
>>> IPVS netns BUG, register sysctl for root ns
>>
>> That tree is based on nf-next-2.6, so I can't pull this into my nf-2.6
>> tree.
>
> Hi Patrick,
>
> Sorry about this.
>
> As it turns out I was mistaken in assuming that the IPVS netns changes
> had been merged into nf-2.6. They haven't, they only exist in net-next-2.6.
>
> All of the recent patches that I have passed on to you relate to the IPVS
> netns changes so nf-next-2.6 is the right place for these fixes. So could
> you please pull the above tree into nf-next-2.6? I do not believe there are
> any nf-2.6 changes at this time.
Thanks, I've pulled it into nf-next-2.6.git.
^ permalink raw reply
* Re: [PATCH v4] smc91x: add devicetree support
From: Nicolas Pitre @ 2011-01-26 15:17 UTC (permalink / raw)
To: Thomas Chou
Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, lkml, David Miller
In-Reply-To: <1296019325-17801-1-git-send-email-thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
On Wed, 26 Jan 2011, Thomas Chou wrote:
> Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
> ---
> v2 specify part numbers in compat as Grant suggested.
> v3 more specific part name.
> v4 include match table only for OF as David suggested.
The smc91x driver relies on many parameters which are platform specific,
such as the bus width capabilities, register spacing due to special bus
wiring, interrupt signal level, LED configuration, whether or not to
configure the chip with a wait state, etc. Will the device tree support
take care of those things?
Nicolas
^ permalink raw reply
* [PATCH] fix validate_link_af in rtnetlink core
From: Kurt Van Dijck @ 2011-01-26 14:55 UTC (permalink / raw)
To: netdev
Hi,
I'm not sure about this patch.
I'm testing an API that uses IFLA_AF_SPEC attribute.
In the rtnetlink core , the set_link_af() member
of the rtnl_af_ops struct receives the nested attribute
(as I expected), but the validate_link_af() member
receives the parent attribute.
IMO, this patch fixes this.
Since I didn't find any code in iproute2 that makes use
of this attribute, I wasn't able to verify this on the userspace
end.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
---
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 310eb80..c6aee92 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1122,8 +1122,7 @@ static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
return -EOPNOTSUPP;
if (af_ops->validate_link_af) {
- err = af_ops->validate_link_af(dev,
- tb[IFLA_AF_SPEC]);
+ err = af_ops->validate_link_af(dev, af);
if (err < 0)
return err;
}
^ permalink raw reply related
* Re: [PATCH] econet: remove compiler warnings
From: Phil Blundell @ 2011-01-26 13:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1296036258.2899.44.camel@edumazet-laptop>
On Wed, Jan 26, 2011 at 11:04:18AM +0100, Eric Dumazet wrote:
> net/econet/af_econet.c: In function ‘econet_sendmsg’:
> net/econet/af_econet.c:494: warning: label ‘error’ defined but not used
> net/econet/af_econet.c:268: warning: unused variable ‘sk’
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks, looks sensible.
Acked-by: Phil Blundell <philb@gnu.org>
p.
^ permalink raw reply
* Re: [RFC 00/20] Proposal for remaining BKL users
From: Arnd Bergmann @ 2011-01-26 13:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Frederic Weisbecker, dri-devel, Mikulas Patocka, H. Peter Anvin,
Ian Kent, linux-cifs, Nick Bowler, linux-x25, Takahiro Hirofuchi,
Ross Cohen, Arnaldo Carvalho de Melo, Evgeniy Dushistov,
Stuart Swales, Thomas Gleixner, Arjan van de Ven, autofs,
Jeff Layton, netdev, Greg KH, linux-kernel, Palash Bandyopadhyay,
linux-fsdevel, Andrew Morton, Andrew
In-Reply-To: <4D400C5D.80004@redhat.com>
On Wednesday 26 January 2011, Mauro Carvalho Chehab wrote:
> I guess you're meaning cx25821, right?
Right, sorry for the typo.
> Palash should take a look on it and review. This is a device that allows
> 12 simultaneous streams, so, I suspect that he'll need to do some
> changes at the locking schema, to avoid performance bottlenecks.
I would be surprised if there was any measurable performance change.
The BKL was used only in the open() function to iterate the device
list, and that code is nowhere on a critical path, as far as I can tell.
Arnd
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: Eric Dumazet @ 2011-01-26 13:26 UTC (permalink / raw)
To: denys; +Cc: Daniel Baluta, netdev
In-Reply-To: <398df9351d5c9aec1ba69511d9dc6a70@visp.net.lb>
Le mercredi 26 janvier 2011 à 15:23 +0200, denys@visp.net.lb a écrit :
> On Wed, 26 Jan 2011 14:17:14 +0100, Eric Dumazet wrote:
> > Le mercredi 26 janvier 2011 à 15:00 +0200, Daniel Baluta a écrit :
> >> Hi,
> >>
> >> > Latest stable, 2.6.37
> >>
> >> Please apply this patch [1] and see if it's still happening.
> >>
> >> thanks,
> >> Daniel
> >>
> >> [1] http://www.spinics.net/lists/netdev/msg152204.html
> >> -
> >
> > I dont think it'll help ;)
> >
> > Denys problem is if one source IP address is used, there is an
> > absolute
> > 64K limit to (IP, port) tuple
> >
> > Only thing you can do is to tune
> > /proc/sys/net/ipv4/ip_local_port_range
> > to get close to 64K limit
> No, it is not one ip source.
> As i mention before, i am binding each instance to different IP before
> connect().
> And when i am having issues and such errors, i am trying httping and
> binding it to some unused ip, but still getting this error.
Ah OK, you definitely want to use REUSEADDR then.
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: denys @ 2011-01-26 13:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Daniel Baluta, netdev
In-Reply-To: <1296047834.2899.62.camel@edumazet-laptop>
On Wed, 26 Jan 2011 14:17:14 +0100, Eric Dumazet wrote:
> Le mercredi 26 janvier 2011 à 15:00 +0200, Daniel Baluta a écrit :
>> Hi,
>>
>> > Latest stable, 2.6.37
>>
>> Please apply this patch [1] and see if it's still happening.
>>
>> thanks,
>> Daniel
>>
>> [1] http://www.spinics.net/lists/netdev/msg152204.html
>> -
>
> I dont think it'll help ;)
>
> Denys problem is if one source IP address is used, there is an
> absolute
> 64K limit to (IP, port) tuple
>
> Only thing you can do is to tune
> /proc/sys/net/ipv4/ip_local_port_range
> to get close to 64K limit
No, it is not one ip source.
As i mention before, i am binding each instance to different IP before
connect().
And when i am having issues and such errors, i am trying httping and
binding it to some unused ip, but still getting this error.
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: Eric Dumazet @ 2011-01-26 13:17 UTC (permalink / raw)
To: Daniel Baluta; +Cc: denys, netdev
In-Reply-To: <AANLkTinDQ-n3Y2_8PtvdWSxkYV8Kvj8on3iEeHsBSFB-@mail.gmail.com>
Le mercredi 26 janvier 2011 à 15:00 +0200, Daniel Baluta a écrit :
> Hi,
>
> > Latest stable, 2.6.37
>
> Please apply this patch [1] and see if it's still happening.
>
> thanks,
> Daniel
>
> [1] http://www.spinics.net/lists/netdev/msg152204.html
> -
I dont think it'll help ;)
Denys problem is if one source IP address is used, there is an absolute
64K limit to (IP, port) tuple
Only thing you can do is to tune /proc/sys/net/ipv4/ip_local_port_range
to get close to 64K limit
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: Daniel Baluta @ 2011-01-26 13:00 UTC (permalink / raw)
To: denys; +Cc: netdev
In-Reply-To: <9e62acde19ef75f3f77468cd81ed7ffd@visp.net.lb>
Hi,
> Latest stable, 2.6.37
Please apply this patch [1] and see if it's still happening.
thanks,
Daniel
[1] http://www.spinics.net/lists/netdev/msg152204.html
^ permalink raw reply
* Re: [PATCH 14/20] staging/appletalk: remove the BKL
From: Arnd Bergmann @ 2011-01-26 12:57 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, acme, netdev
In-Reply-To: <20110125.142926.246535705.davem@davemloft.net>
On Tuesday 25 January 2011, David Miller wrote:
> If you're moving appletalk to staging because "nobody is motivated
> enough to remove the BKL" and then you actually do the work to remove
> the BKL, I really don't see any point in doing the whole staging
> thing.
>
> We always keep an eye on every protocol that sits under the top-level
> net/. Every socket API change propagates, as does every other
> networking API change that matters for those protocols.
Ok, fair enough. I've removed the "move to staging" patch now from my
series. I'm going to need some help with testing, or at least thoroughly
reviewing the patch, since I am not extremely confident in my own work
there.
Arnd
^ permalink raw reply
* RE: bnx2 cards intermittantly going offline
From: Mills, Tony @ 2011-01-26 12:44 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev@vger.kernel.org
In-Reply-To: <1295373358.8131.4.camel@HP1>
Hi, Thanks for your response.
I have done some further investigation and found that we have had a massive amount of interrupts occurring on our Broadcom cards, i have set the affinity for irq 36 and 48 to run on the first two vcpu's on the box and the java processes to run on the others. I have also replaced the debian bnx2 driver with the latest from the Broadcom website and made the rx ring buffer to 4080, this has stopped a multiplexed server running at 1.6 cycles per second from missing cycles due to interrupts on the interface and allowing much better processing time, and the ring buffer up at 4080 stops the rx_fw_discards i was seeing periodically, (even upping that to 1020 or 2040 did not sort the issue but the maximum setting from the Broadcom driver does.
I am now monitoring the system to see if the card ever becomes unresponsive. But i do have a question.
If i setup the smp_affinity with a mask of cpu 0 and 1 (the first two on the box) for the APIC-fasteoi irq's for the Ethernet devices, it appears that the kernel does not balance and will continue to use the same cpu to do the interrupts even though there is processing power on the other one. Is this a known issue or am i doing something wrong?
Can i add it's on an dell r610 with a 12 core intel Xeon X5680, this shows up as 24 vcpu's.
Best Regards
Tony Mills
-----Original Message-----
From: Michael Chan [mailto:mchan@broadcom.com]
Sent: 18 January 2011 17:56
To: Mills, Tony
Cc: netdev@vger.kernel.org
Subject: Re: bnx2 cards intermittantly going offline
On Tue, 2011-01-18 at 02:54 -0800, Mills, Tony wrote:
> Last night i setup a machine to monitor overnight and at 3:52 this
> morning it became unresponsive.
>
When it becomes unresponsive, please send some packets to the NIC (such
as ping) and monitor statistics with ethtool -S. See if the packets are
being received or discarded. Also, run tcpdump on the machine to see if
the packets are properly received by the stack. Thanks.
--
IMPORTANT NOTICE
The sender does not guarantee that this message, including any attachment, is secure
or virus free. Also, it is confidential and may be privileged or otherwise protected
from disclosure. If you are not the intended recipient, do not disclose or copy it
or its contents. Please telephone or email the sender and delete the message
entirely from your system.
Jagex Limited is a company registered in England & Wales with company number
03982706 and a registered office at St John's Innovation Centre, Cowley Road,
Cambridge, CB4 0WS, UK.
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: denys @ 2011-01-26 12:35 UTC (permalink / raw)
To: Daniel Baluta; +Cc: netdev
In-Reply-To: <AANLkTikSvf8bNK2_eHg+cWQJLz-56_88mrf0ttJX3W=0@mail.gmail.com>
On Wed, 26 Jan 2011 14:23:44 +0200, Daniel Baluta wrote:
> Hi,
>
> On Wed, Jan 26, 2011 at 2:14 PM, <denys@visp.net.lb> wrote:
>> I am running server (TCP accelerator), which is initiating more than
>> 40K
>> connections.
>> Each instance of server bound to separate IP, and each of them
>> handling
>> around 5-10K connections.
>> At moments, when i have excessive connect/disconnect events if i try
>> to
>> establish connection even from IP is not used,
>> during bind() i am getting errno "Address already in use".
>> What can be the issue?
>> Will it help if i increase in kernel hardcoded limit from 64K TCP
>> bind hash
>> entries to higher values?
>
> Please provide more information. What kernel version are you using?
> Are you binding on a SO_REUSEADDR socket right?
Latest stable, 2.6.37
No, but trying with it now. At same time i think it is not correct, if
i try to bind to "unused" for any connections IP, and it will return
such error.
It is not listening socket, it is outbound connection
s = socket(...)
memset(&name,0x0,sizeof(name));
name.sin_family=AF_INET;
name.sin_addr.s_addr=s_stx->src_ip;
name.sin_port=0;
bind()
connect()
Now i will try to put between socket and bind
setsockopt(netsocket,SOL_SOCKET,SO_REUSEADDR,(void*)&tmpint,sizeof(tmpint));
But IMHO it is not very correct for outgoing connections.
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: Daniel Baluta @ 2011-01-26 12:23 UTC (permalink / raw)
To: denys; +Cc: netdev
In-Reply-To: <8cdb2dde69120a8668b31e2050916493@visp.net.lb>
Hi,
On Wed, Jan 26, 2011 at 2:14 PM, <denys@visp.net.lb> wrote:
> I am running server (TCP accelerator), which is initiating more than 40K
> connections.
> Each instance of server bound to separate IP, and each of them handling
> around 5-10K connections.
> At moments, when i have excessive connect/disconnect events if i try to
> establish connection even from IP is not used,
> during bind() i am getting errno "Address already in use".
> What can be the issue?
> Will it help if i increase in kernel hardcoded limit from 64K TCP bind hash
> entries to higher values?
Please provide more information. What kernel version are you using?
Are you binding on a SO_REUSEADDR socket right?
thanks,
Daniel.
^ permalink raw reply
* 40k+ outbound connections and bind() problem
From: denys @ 2011-01-26 12:14 UTC (permalink / raw)
To: netdev
I am running server (TCP accelerator), which is initiating more than
40K connections.
Each instance of server bound to separate IP, and each of them handling
around 5-10K connections.
At moments, when i have excessive connect/disconnect events if i try to
establish connection even from IP is not used,
during bind() i am getting errno "Address already in use".
What can be the issue?
Will it help if i increase in kernel hardcoded limit from 64K TCP bind
hash entries to higher values?
^ permalink raw reply
* Re: [RFC 00/20] Proposal for remaining BKL users
From: Mauro Carvalho Chehab @ 2011-01-26 11:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Frederic Weisbecker, dri-devel, Mikulas Patocka, H. Peter Anvin,
Ian Kent, linux-cifs, Nick Bowler, linux-x25, Takahiro Hirofuchi,
Palash Bandyopadhyay, Ross Cohen, Arnaldo Carvalho de Melo,
Evgeniy Dushistov, Stuart Swales, Thomas Gleixner,
Arjan van de Ven, autofs, Jeff Layton, netdev, Greg KH,
linux-kernel, Palash Bandyopadhyay, linux-fsdevel
In-Reply-To: <201101261231.30390.arnd@arndb.de>
Em 26-01-2011 09:31, Arnd Bergmann escreveu:
> On Wednesday 26 January 2011, Greg KH wrote:
>> On Tue, Jan 25, 2011 at 11:17:14PM +0100, Arnd Bergmann wrote:
>>> I've gone through all the code in the kernel that
>>> uses the big kernel lock and come up with a solution
>>> that seems at least half-reasonable for each of them.
>>>
>>> The decisions are somewhat arbitrary, but here is
>>> what I'd suggest we do:
>>>
>>> * Remove in 2.6.39:
>>> i830, autofs3, smbfs
>>
>> I thought some people really wanted to keep i830. Or was that i810?
>> I'll drop autofs3 and smbfs, thanks.
>
> i810 needs to be kept, i830 is obsolete, see the patch changelogs
> there. I assume that Dave Airlie will take both patches (i810 BKL
> removal and i830 removal) into his 2.6.39 queue.
>
>>> * Work around in an ugly way, but keep alive:
>>> * ufs, ipx, i810, cx25721
>>>
>>> * Fix properly:
>>> * usbip, go7007, adfs, x25
>>
>> Thanks for the usbip and go7007 patches, I'll queue them up.
>
> It would be good if you could also take the cx25721 patch. It's
> not the nicest one I've done, but it's a bug fix nonetheless.
I guess you're meaning cx25821, right?
Palash should take a look on it and review. This is a device that allows
12 simultaneous streams, so, I suspect that he'll need to do some
changes at the locking schema, to avoid performance bottlenecks.
Cheers,
Mauro
^ permalink raw reply
* Re: [PATCH 2/2] xen: netfront: Drop GSO SKBs which do not have csum_blank.
From: Ian Campbell @ 2011-01-26 11:56 UTC (permalink / raw)
To: David Miller
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
netdev@vger.kernel.org
In-Reply-To: <20110125.194405.226769333.davem@davemloft.net>
On Wed, 2011-01-26 at 03:44 +0000, David Miller wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Tue, 25 Jan 2011 17:10:00 +0000
>
> > The Linux network stack expects all GSO SKBs to have ip_summed ==
> > CHECKSUM_PARTIAL (which implies that the frame contains a partial
> > checksum) and the Xen network ring protocol similarly expects an SKB
> > which has GSO set to also have NETRX_csum_blank (which also implies a
> > partial checksum). Therefore drop such frames on receive otherwise
> > they will trigger the warning in skb_gso_segment.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> The GSO code does in fact warn in the logs about this situation, but
> it _DOES NOT_ drop the packet. Therefore, either you guys should do
> the same or we should make the generic code drop too.
Ah, yes. I misread the handling of an error from pskb_expand_head() in
skb_gso_segment() and thought it was a more general error return
covering the entire case.
> I think the generic code is doing the right thing, therefore what you
> should probably do is put the checksum of the SKB into the right state
> when you detect this situation (and perhaps bump a ethtool driver
> local statistic which specifically tracks this exact event).
Yes, I think this is a good idea. I'll come up with a patch which does
this.
> Or, even better, you should fix whatever causes this in the first
> place.
Sure, that has already been done but the proper fix is in another guest,
with a secondary robustness fix in netback (similar to this one, so I'll
take your advice from above on board in that context too).
The intention here was to be robust in the face of unfixed guests
sharing the same host or future netback bugs etc.
> Dropping frames ought to be the last option, stuff like this is
> impossible to debug if someone starts wondering why they are getting
> frame drops.
>
> You don't even account for this in a unique statistic somewhere, so
> people can figure out the actual spcific _reason_ for the drop. They
> will just see "rx_error" and scratch their heads.
>
> Anyways, I think dropping is fundamentally wrong, so I'm not applying
> this.
You've convinced me too, thanks for the feedback.
Thanks,
Ian.
^ permalink raw reply
* Re: [RFC 00/20] Proposal for remaining BKL users
From: Arnd Bergmann @ 2011-01-26 11:31 UTC (permalink / raw)
To: Greg KH
Cc: Mauro Carvalho Chehab, Frederic Weisbecker, dri-devel,
Mikulas Patocka, H. Peter Anvin, Ian Kent, linux-cifs,
Nick Bowler, linux-x25, Takahiro Hirofuchi, Ross Cohen,
Arnaldo Carvalho de Melo, Evgeniy Dushistov, Stuart Swales,
Thomas Gleixner, Arjan van de Ven, autofs, Jeff Layton, netdev,
linux-kernel, Palash Bandyopadhyay, linux-fsdevel, Andrew Morton
In-Reply-To: <20110126022223.GB28072@suse.de>
On Wednesday 26 January 2011, Greg KH wrote:
> On Tue, Jan 25, 2011 at 11:17:14PM +0100, Arnd Bergmann wrote:
> > I've gone through all the code in the kernel that
> > uses the big kernel lock and come up with a solution
> > that seems at least half-reasonable for each of them.
> >
> > The decisions are somewhat arbitrary, but here is
> > what I'd suggest we do:
> >
> > * Remove in 2.6.39:
> > i830, autofs3, smbfs
>
> I thought some people really wanted to keep i830. Or was that i810?
> I'll drop autofs3 and smbfs, thanks.
i810 needs to be kept, i830 is obsolete, see the patch changelogs
there. I assume that Dave Airlie will take both patches (i810 BKL
removal and i830 removal) into his 2.6.39 queue.
> > * Work around in an ugly way, but keep alive:
> > * ufs, ipx, i810, cx25721
> >
> > * Fix properly:
> > * usbip, go7007, adfs, x25
>
> Thanks for the usbip and go7007 patches, I'll queue them up.
It would be good if you could also take the cx25721 patch. It's
not the nicest one I've done, but it's a bug fix nonetheless.
Thanks,
Arnd
^ permalink raw reply
* Re: [patch] kconfig: unify GENERIC_ISA_DMA and ISA_DMA_API
From: Russell King - ARM Linux @ 2011-01-26 11:29 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Ralf Baechle, Kyle McMartin, James Bottomley,
Benjamin Herrenschmidt, Thomas Gleixner, H. Peter Anvin,
Ingo Molnar, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
x86, linux-arch, netdev, linux-scsi, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1101251706040.9641@chino.kir.corp.google.com>
On Tue, Jan 25, 2011 at 05:06:28PM -0800, David Rientjes wrote:
> CONFIG_GENERIC_ISA_DMA and CONFIG_ISA_DMA_API usually have dependencies
> on one another depending on the architecture and generic kernel code uses
> either to determine whether an ISA-style DMA API is configured.
Wrong.
GENERIC_ISA_DMA enables support for the standard ISA DMA allocator found
in kernel/dma.c
ISA_DMA_API says that a platform supports the ISA DMA interfaces.
An architecture can provide the ISA DMA interfaces, but not use the
standard ISA DMA allocator found in kernel/dma.c. Such as the one in
arch/arm/kernel/dma.c.
So on ARM, we have platforms where ISA_DMA_API=y but GENERIC_ISA_DMA=n.
> This patch unifies both options and consolidates them into a single
> option: CONFIG_GENERIC_ISA_DMA. It is also a prerequisite for a 1% text
> savings for a future x86 patch that allows these options to be disabled
> on that architecture when CONFIG_ZONE_DMA also becomes configurable.
NAK. This is wrong.
^ 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