* [PATCH 5/5] netdev: bfin_mac: disable hardware checksum if writeback cache is enabled
From: Mike Frysinger @ 2011-01-10 12:54 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel, Sonic Zhang
In-Reply-To: <1294664073-1950-1-git-send-email-vapier@gentoo.org>
From: Sonic Zhang <sonic.zhang@analog.com>
With writeback caches, corrupted RX packets will be sent up the stack
without any error markings.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/net/bfin_mac.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bfin_mac.h b/drivers/net/bfin_mac.h
index c1a0d66..f8559ac 100644
--- a/drivers/net/bfin_mac.h
+++ b/drivers/net/bfin_mac.h
@@ -17,7 +17,14 @@
#include <linux/etherdevice.h>
#include <linux/bfin_mac.h>
+/*
+ * Disable hardware checksum for bug #5600 if writeback cache is
+ * enabled. Otherwize, corrupted RX packet will be sent up stack
+ * without error mark.
+ */
+#ifndef CONFIG_BFIN_EXTMEM_WRITEBACK
#define BFIN_MAC_CSUM_OFFLOAD
+#endif
#define TX_RECLAIM_JIFFIES (HZ / 5)
--
1.7.4.rc1
^ permalink raw reply related
* [PATCH 1/5] netdev: bfin_mac: clean up printk messages
From: Mike Frysinger @ 2011-01-10 12:54 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller
Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
Use netdev_* and pr_* helper funcs for output rather than printk.
Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
---
drivers/net/bfin_mac.c | 65 +++++++++++++++++++++--------------------------
1 files changed, 29 insertions(+), 36 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index ce1e5e9..a572bcb 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -8,6 +8,11 @@
* Licensed under the GPL-2 or later.
*/
+#define DRV_VERSION "1.1"
+#define DRV_DESC "Blackfin on-chip Ethernet MAC driver"
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
@@ -41,12 +46,7 @@
#include "bfin_mac.h"
-#define DRV_NAME "bfin_mac"
-#define DRV_VERSION "1.1"
-#define DRV_AUTHOR "Bryan Wu, Luke Yang"
-#define DRV_DESC "Blackfin on-chip Ethernet MAC driver"
-
-MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_AUTHOR("Bryan Wu, Luke Yang");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION(DRV_DESC);
MODULE_ALIAS("platform:bfin_mac");
@@ -189,8 +189,7 @@ static int desc_list_init(void)
/* allocate a new skb for next time receive */
new_skb = dev_alloc_skb(PKT_BUF_SZ + NET_IP_ALIGN);
if (!new_skb) {
- printk(KERN_NOTICE DRV_NAME
- ": init: low on mem - packet dropped\n");
+ pr_notice("init: low on mem - packet dropped\n");
goto init_error;
}
skb_reserve(new_skb, NET_IP_ALIGN);
@@ -240,7 +239,7 @@ static int desc_list_init(void)
init_error:
desc_list_free();
- printk(KERN_ERR DRV_NAME ": kmalloc failed\n");
+ pr_err("kmalloc failed\n");
return -ENOMEM;
}
@@ -259,8 +258,7 @@ static int bfin_mdio_poll(void)
while ((bfin_read_EMAC_STAADD()) & STABUSY) {
udelay(1);
if (timeout_cnt-- < 0) {
- printk(KERN_ERR DRV_NAME
- ": wait MDC/MDIO transaction to complete timeout\n");
+ pr_err("wait MDC/MDIO transaction to complete timeout\n");
return -ETIMEDOUT;
}
}
@@ -350,9 +348,9 @@ static void bfin_mac_adjust_link(struct net_device *dev)
opmode &= ~RMII_10;
break;
default:
- printk(KERN_WARNING
- "%s: Ack! Speed (%d) is not 10/100!\n",
- DRV_NAME, phydev->speed);
+ netdev_warn(dev,
+ "Ack! Speed (%d) is not 10/100!\n",
+ phydev->speed);
break;
}
bfin_write_EMAC_OPMODE(opmode);
@@ -417,14 +415,13 @@ static int mii_probe(struct net_device *dev, int phy_mode)
/* now we are supposed to have a proper phydev, to attach to... */
if (!phydev) {
- printk(KERN_INFO "%s: Don't found any phy device at all\n",
- dev->name);
+ netdev_err(dev, "no phy device found\n");
return -ENODEV;
}
if (phy_mode != PHY_INTERFACE_MODE_RMII &&
phy_mode != PHY_INTERFACE_MODE_MII) {
- printk(KERN_INFO "%s: Invalid phy interface mode\n", dev->name);
+ netdev_err(dev, "invalid phy interface mode\n");
return -EINVAL;
}
@@ -432,7 +429,7 @@ static int mii_probe(struct net_device *dev, int phy_mode)
0, phy_mode);
if (IS_ERR(phydev)) {
- printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
+ netdev_err(dev, "could not attach PHY\n");
return PTR_ERR(phydev);
}
@@ -453,11 +450,10 @@ static int mii_probe(struct net_device *dev, int phy_mode)
lp->old_duplex = -1;
lp->phydev = phydev;
- printk(KERN_INFO "%s: attached PHY driver [%s] "
- "(mii_bus:phy_addr=%s, irq=%d, mdc_clk=%dHz(mdc_div=%d)"
- "@sclk=%dMHz)\n",
- DRV_NAME, phydev->drv->name, dev_name(&phydev->dev), phydev->irq,
- MDC_CLK, mdc_div, sclk/1000000);
+ pr_info("attached PHY driver [%s] "
+ "(mii_bus:phy_addr=%s, irq=%d, mdc_clk=%dHz(mdc_div=%d)@sclk=%dMHz)\n",
+ phydev->drv->name, dev_name(&phydev->dev), phydev->irq,
+ MDC_CLK, mdc_div, sclk/1000000);
return 0;
}
@@ -502,7 +498,7 @@ bfin_mac_ethtool_setsettings(struct net_device *dev, struct ethtool_cmd *cmd)
static void bfin_mac_ethtool_getdrvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
{
- strcpy(info->driver, DRV_NAME);
+ strcpy(info->driver, KBUILD_MODNAME);
strcpy(info->version, DRV_VERSION);
strcpy(info->fw_version, "N/A");
strcpy(info->bus_info, dev_name(&dev->dev));
@@ -827,8 +823,7 @@ static void bfin_tx_hwtstamp(struct net_device *netdev, struct sk_buff *skb)
while ((!(bfin_read_EMAC_PTP_ISTAT() & TXTL)) && (--timeout_cnt))
udelay(1);
if (timeout_cnt == 0)
- printk(KERN_ERR DRV_NAME
- ": fails to timestamp the TX packet\n");
+ netdev_err(netdev, "timestamp the TX packet failed\n");
else {
struct skb_shared_hwtstamps shhwtstamps;
u64 ns;
@@ -1083,8 +1078,7 @@ static void bfin_mac_rx(struct net_device *dev)
* we which case we simply drop the packet
*/
if (current_rx_ptr->status.status_word & RX_ERROR_MASK) {
- printk(KERN_NOTICE DRV_NAME
- ": rx: receive error - packet dropped\n");
+ netdev_notice(dev, "rx: receive error - packet dropped\n");
dev->stats.rx_dropped++;
goto out;
}
@@ -1094,8 +1088,7 @@ static void bfin_mac_rx(struct net_device *dev)
new_skb = dev_alloc_skb(PKT_BUF_SZ + NET_IP_ALIGN);
if (!new_skb) {
- printk(KERN_NOTICE DRV_NAME
- ": rx: low on mem - packet dropped\n");
+ netdev_notice(dev, "rx: low on mem - packet dropped\n");
dev->stats.rx_dropped++;
goto out;
}
@@ -1213,7 +1206,7 @@ static int bfin_mac_enable(struct phy_device *phydev)
int ret;
u32 opmode;
- pr_debug("%s: %s\n", DRV_NAME, __func__);
+ pr_debug("%s\n", __func__);
/* Set RX DMA */
bfin_write_DMA1_NEXT_DESC_PTR(&(rx_list_head->desc_a));
@@ -1323,7 +1316,7 @@ static void bfin_mac_set_multicast_list(struct net_device *dev)
u32 sysctl;
if (dev->flags & IFF_PROMISC) {
- printk(KERN_INFO "%s: set to promisc mode\n", dev->name);
+ netdev_info(dev, "set promisc mode\n");
sysctl = bfin_read_EMAC_OPMODE();
sysctl |= PR;
bfin_write_EMAC_OPMODE(sysctl);
@@ -1393,7 +1386,7 @@ static int bfin_mac_open(struct net_device *dev)
* address using ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
*/
if (!is_valid_ether_addr(dev->dev_addr)) {
- printk(KERN_WARNING DRV_NAME ": no valid ethernet hw addr\n");
+ netdev_warn(dev, "no valid ethernet hw addr\n");
return -EINVAL;
}
@@ -1558,7 +1551,7 @@ static int __devinit bfin_mac_probe(struct platform_device *pdev)
bfin_mac_hwtstamp_init(ndev);
/* now, print out the card info, in a short format.. */
- dev_info(&pdev->dev, "%s, Version %s\n", DRV_DESC, DRV_VERSION);
+ netdev_info(ndev, "%s, Version %s\n", DRV_DESC, DRV_VERSION);
return 0;
@@ -1650,7 +1643,7 @@ static int __devinit bfin_mii_bus_probe(struct platform_device *pdev)
* so set the GPIO pins to Ethernet mode
*/
pin_req = mii_bus_pd->mac_peripherals;
- rc = peripheral_request_list(pin_req, DRV_NAME);
+ rc = peripheral_request_list(pin_req, KBUILD_MODNAME);
if (rc) {
dev_err(&pdev->dev, "Requesting peripherals failed!\n");
return rc;
@@ -1739,7 +1732,7 @@ static struct platform_driver bfin_mac_driver = {
.resume = bfin_mac_resume,
.suspend = bfin_mac_suspend,
.driver = {
- .name = DRV_NAME,
+ .name = KBUILD_MODNAME,
.owner = THIS_MODULE,
},
};
--
1.7.4.rc1
^ permalink raw reply related
* Re: [PATCH 3/3] netlink: support setting devgroup parameters
From: jamal @ 2011-01-10 13:14 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: netdev, Octavian Purdila
In-Reply-To: <1294659524-22509-4-git-send-email-ddvlad@rosedu.org>
Nice - short and sweet.
IMO: I dont think you need this new attribute, IFLA_GROUP
should suffice...
You can use the trick that if a <=0 ifindex is specified,
and no name is passed but a GROUP is passed, then we
operate on the group i.e something like:
if (ifm->ifi_index > 0)
dev = __dev_get_by_index(net, ifm->ifi_index);
else {
if (tb[IFLA_IFNAME])
dev = __dev_get_by_name(net, ifname);
else if (tb[IFLA_GROUP])
new/get/set/del specific stuff..
else
return -EINVAL;
}
cheers,
jamal
On Mon, 2011-01-10 at 13:38 +0200, Vlad Dogaru wrote:
> Add a new type of message, IFLA_FILTERGROUP, which, if present in a
> userspace request, specifies that parameters should be changed for all
> devices in the group.
>
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 13:31 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D24DB2C.9040104-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Wolfgang,
A few thoughts ...
On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
> >
> > obj-y += usb/
> > +obj-y += softing/
>
> Please use "obj-$(CONFIG_CAN_SOFTING)" here.
As I explained, softing does not depend on softing_cs or vice versa,
which makes "obj-$(CONFIG_CAN_SOFTING)" not right.
> > + if (type != 0xffff) {
> > + dev_alert(&card->pdev->dev, "firware starts with type 0x%04x\n",
>
> Typo?
>
??
> > +
> > +int softing_default_output(struct net_device *netdev)
> > +{
> > + struct softing_priv *priv = netdev_priv(netdev);
> > + struct softing *card = priv->card;
> > +
> > + switch (priv->chip) {
> > + case 1000:
> > + if (card->pdat->generation < 2)
> > + return 0xfb;
> > + return 0xfa;
> > + case 5:
> > + return 0x60;
> > + default:
> > + return 0x40;
> > + }
> > +}
>
> Again, some magic constants.
The thing is, I didn't create those number, nor do I precisely know
which are the right ones, or how I would name those.
Since they're used one, I tought this would work.
>
> > + ret = netif_rx(skb);
> > + if (ret == NET_RX_DROP)
> > + ++netdev->stats.rx_dropped;
>
> Hm, I wonder if all Socket-CAN drivers should handle the return value of
> netif_rx that way?
>
No, they should not.
After a seconds look, I'm a tiny little bit wrong here.
I should only increment rx_dropped when it's a real received message,
and not a virtual constructed one (bus crtls).
I moved this thing to the rx data handler.
Maybe, a common CAN rx function is usefull to properly deal with
the can_echo_skb & friends.
>
> > + priv->can.ctrlmode_supported =
> > + CAN_CTRLMODE_3_SAMPLES;/* | CAN_CTRLMODE_BERR_REPORTING */;
>
> Hm, any chance to support CAN_CTRLMODE_BERR_REPORTING? If not, please
> remove the comment.
I think I better try to write it properly without, and add error reporting
later, after serious testing of the error reporting on a softing card.
The primary goal now is get this driver in mainline kernel since PCMCIA
has been changing recently, and I found it hard to keep up. So, first things
first ...
Kurt
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Wolfram Sang @ 2011-01-10 13:40 UTC (permalink / raw)
To: Kurt Van Dijck
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Grandegger
In-Reply-To: <20110110133112.GA324-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 770 bytes --]
> > > + if (type != 0xffff) {
> > > + dev_alert(&card->pdev->dev, "firware starts with type 0x%04x\n",
> >
> > Typo?
> >
> ??
I think he means "fir[m]ware"
> > > +
> > > +int softing_default_output(struct net_device *netdev)
> > > +{
> > > + struct softing_priv *priv = netdev_priv(netdev);
> > > + struct softing *card = priv->card;
> > > +
> > > + switch (priv->chip) {
> > > + case 1000:
> > > + if (card->pdat->generation < 2)
> > > + return 0xfb;
> > > + return 0xfa;
A ternary operator might look nicer here because of just a single return.
Best wishes,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 13:41 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: jamal, Octavian Purdila, netdev
In-Reply-To: <1294659524-22509-1-git-send-email-ddvlad@rosedu.org>
On Mon, 2011-01-10 at 13:38 +0200, Vlad Dogaru wrote:
> This patchset implements network device grouping and simple manipulation
> of groups. Netlink has been update to provide group information and
> means of applying changes to members of a specific group via a single
> message.
Can you explain the purpose of this? I'm wondering if it would make
sense to automatically group all virtual interfaces belonging to a
single 802.11 device, for instance.
johannes
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 13:44 UTC (permalink / raw)
To: Wolfram Sang
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Grandegger
In-Reply-To: <20110110134006.GC31011-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Mon, Jan 10, 2011 at 02:40:06PM +0100, Wolfram Sang wrote:
> > > > + if (type != 0xffff) {
> > > > + dev_alert(&card->pdev->dev, "firware starts with type 0x%04x\n",
> > >
> > > Typo?
> > >
> > ??
>
> I think he means "fir[m]ware"
>
Thanks. Can't imagine anymore how I couldn't see it.
Kurt
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Eric Dumazet @ 2011-01-10 13:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110106205549.0de56de1@nehalam>
Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
>
> The problem is that large tables of pointers in kernel require either
> contiguous allocation or some indirect table algorithm.
>
Here is a v3 version with an array based queue for O(1) peek_random
complexity.
Could you send the iproute2 patch so that I can test it ?
Thanks !
diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
index e69de29..ea9db00 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -0,0 +1,388 @@
+/*
+ * net/sched/sch_choke.c CHOKE scheduler
+ *
+ * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
+ * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/skbuff.h>
+#include <linux/reciprocal_div.h>
+#include <net/pkt_sched.h>
+#include <net/inet_ecn.h>
+#include <net/red.h>
+
+/* CHOKe stateless AQM for fair bandwidth allocation
+ =================================================
+
+ CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
+ unresponsive flows) is a variant of RED that penalizes misbehaving flows but
+ maintains no flow state. The difference from RED is an additional step
+ during the enqueuing process. If average queue size is over the
+ low threshold (qmin), a packet is chosen at random from the queue.
+ If both the new and chosen packet are from the same flow, both
+ are dropped. Unlike RED, CHOKe is not a "classful" qdisc because it
+ needs to access packets in queue randomly.
+
+ Source:
+ R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
+ Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
+ IEEE INFOCOM, 2000.
+
+ A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
+ Characteristics", IEEE/ACM Transactions on Networking, 2004
+
+ */
+
+struct choke_sched_data {
+ u32 limit;
+ unsigned char flags;
+
+ struct red_parms parms;
+ struct red_stats stats;
+
+ unsigned int head;
+ unsigned int tail;
+ unsigned int holes;
+ unsigned int tab_mask; /* size - 1 */
+ struct sk_buff **tab;
+};
+
+static inline unsigned int choke_len(const struct choke_sched_data *q)
+{
+ return (q->tail - q->head) & q->tab_mask;
+}
+
+/* deliver a random number between 0 and N - 1 */
+static inline u32 random_N(unsigned int N)
+{
+ return reciprocal_divide(random32(), N);
+}
+
+/* Select a packet at random from the queue in O(1) */
+static struct sk_buff *choke_peek_random(struct choke_sched_data *q, unsigned int *pidx)
+{
+ *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
+ return q->tab[*pidx];
+}
+
+
+static inline int use_ecn(const struct choke_sched_data *q)
+{
+ return q->flags & TC_RED_ECN;
+}
+
+static inline int use_harddrop(const struct choke_sched_data *q)
+{
+ return q->flags & TC_RED_HARDDROP;
+}
+
+static inline void choke_zap_head_holes(struct choke_sched_data *q)
+{
+ while (q->holes && q->tab[q->head] == NULL) {
+ q->head = (q->head + 1) & q->tab_mask;
+ q->holes--;
+ }
+}
+
+static inline void choke_zap_tail_holes(struct choke_sched_data *q)
+{
+ while (q->holes && q->tab[q->tail - 1] == NULL) {
+ q->tail = (q->tail - 1) & q->tab_mask;
+ q->holes--;
+ }
+}
+
+static void choke_drop_by_idx(struct choke_sched_data *q, unsigned int idx)
+{
+ q->tab[idx] = NULL;
+ q->holes++;
+ choke_zap_head_holes(q);
+ choke_zap_tail_holes(q);
+}
+
+
+static int choke_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct red_parms *p = &q->parms;
+
+ p->qavg = red_calc_qavg(p, choke_len(q) - q->holes);
+ if (red_is_idling(p))
+ red_end_of_idle_period(p);
+
+ if (p->qavg <= p->qth_min)
+ p->qcount = -1;
+ else {
+ struct sk_buff *oskb;
+ unsigned int idx;
+
+ /* Draw a packet at random from queue */
+ oskb = choke_peek_random(q, &idx);
+
+ /* Both packets from same flow ? */
+ if (oskb && skb_get_rxhash(oskb) == skb_get_rxhash(skb)) {
+ /* Drop both packets */
+ choke_drop_by_idx(q, idx);
+ qdisc_drop(oskb, sch);
+ goto congestion_drop;
+ }
+
+ if (p->qavg > p->qth_max) {
+ p->qcount = -1;
+
+ sch->qstats.overlimits++;
+ if (use_harddrop(q) || !use_ecn(q) ||
+ !INET_ECN_set_ce(skb)) {
+ q->stats.forced_drop++;
+ goto congestion_drop;
+ }
+
+ q->stats.forced_mark++;
+ }
+
+ if (++p->qcount) {
+ if (red_mark_probability(p, p->qavg)) {
+ p->qcount = 0;
+ p->qR = red_random(p);
+
+ sch->qstats.overlimits++;
+ if (!use_ecn(q) || !INET_ECN_set_ce(skb)) {
+ q->stats.prob_drop++;
+ goto congestion_drop;
+ }
+
+ q->stats.prob_mark++;
+ }
+ } else
+ p->qR = red_random(p);
+ }
+
+ /* Admit new packet */
+ if (likely(choke_len(q) < q->limit)) {
+ q->tab[q->tail] = skb;
+ q->tail = (q->tail + 1) & q->tab_mask;
+ sch->qstats.backlog += qdisc_pkt_len(skb);
+ __qdisc_update_bstats(sch, qdisc_pkt_len(skb));
+ return NET_XMIT_SUCCESS;
+ }
+ q->stats.pdrop++;
+ sch->qstats.drops++;
+ kfree_skb(skb);
+ return NET_XMIT_DROP;
+
+ congestion_drop:
+ qdisc_drop(skb, sch);
+ return NET_XMIT_CN;
+}
+
+static struct sk_buff *choke_dequeue(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct sk_buff *skb;
+
+ if (q->head == q->tail) {
+ if (!red_is_idling(&q->parms))
+ red_start_of_idle_period(&q->parms);
+ return NULL;
+ }
+ skb = q->tab[q->head];
+ q->tab[q->head] = NULL; /* not really needed */
+ q->head = (q->head + 1) & q->tab_mask;
+ choke_zap_head_holes(q);
+ sch->qstats.backlog -= qdisc_pkt_len(skb);
+
+ return skb;
+}
+
+static unsigned int choke_drop(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ unsigned int len;
+
+ len = qdisc_queue_drop(sch);
+
+ if (len > 0)
+ q->stats.other++;
+ else {
+ if (!red_is_idling(&q->parms))
+ red_start_of_idle_period(&q->parms);
+ }
+
+ return len;
+}
+
+static void choke_reset(struct Qdisc* sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ red_restart(&q->parms);
+}
+
+static const struct nla_policy choke_policy[TCA_RED_MAX + 1] = {
+ [TCA_RED_PARMS] = { .len = sizeof(struct tc_red_qopt) },
+ [TCA_RED_STAB] = { .len = RED_STAB_SIZE },
+};
+
+
+static void choke_free(void *addr)
+{
+ if (addr) {
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
+ }
+}
+
+static int choke_change(struct Qdisc *sch, struct nlattr *opt)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct nlattr *tb[TCA_RED_MAX + 1];
+ struct tc_red_qopt *ctl;
+ int err;
+ struct sk_buff **old = NULL;
+ unsigned int mask;
+
+ if (opt == NULL)
+ return -EINVAL;
+
+ err = nla_parse_nested(tb, TCA_RED_MAX, opt, choke_policy);
+ if (err < 0)
+ return err;
+
+ if (tb[TCA_RED_PARMS] == NULL ||
+ tb[TCA_RED_STAB] == NULL)
+ return -EINVAL;
+
+ ctl = nla_data(tb[TCA_RED_PARMS]);
+
+ mask = roundup_pow_of_two(ctl->limit + 1) - 1;
+ if (mask != q->tab_mask) {
+ struct sk_buff **ntab = kcalloc(mask + 1, sizeof(struct sk_buff *),
+ GFP_KERNEL);
+ if (!ntab)
+ ntab = vzalloc((mask + 1) * sizeof(struct sk_buff *));
+ if (!ntab)
+ return -ENOMEM;
+ sch_tree_lock(sch);
+ old = q->tab;
+ if (old) {
+ unsigned int tail = 0;
+
+ while (q->head != q->tail) {
+ ntab[tail++] = q->tab[q->head];
+ q->head = (q->head + 1) & q->tab_mask;
+ }
+ q->head = 0;
+ q->tail = tail;
+ }
+ q->tab_mask = mask;
+ q->holes = 0;
+ } else
+ sch_tree_lock(sch);
+ q->flags = ctl->flags;
+ q->limit = ctl->limit;
+
+ red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
+ ctl->Plog, ctl->Scell_log,
+ nla_data(tb[TCA_RED_STAB]));
+
+ if (q->head == q->tail)
+ red_end_of_idle_period(&q->parms);
+
+ sch_tree_unlock(sch);
+ choke_free(old);
+ return 0;
+}
+
+static int choke_init(struct Qdisc* sch, struct nlattr *opt)
+{
+ return choke_change(sch, opt);
+}
+
+static int choke_dump(struct Qdisc *sch, struct sk_buff *skb)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct nlattr *opts = NULL;
+ struct tc_red_qopt opt = {
+ .limit = q->limit,
+ .flags = q->flags,
+ .qth_min = q->parms.qth_min >> q->parms.Wlog,
+ .qth_max = q->parms.qth_max >> q->parms.Wlog,
+ .Wlog = q->parms.Wlog,
+ .Plog = q->parms.Plog,
+ .Scell_log = q->parms.Scell_log,
+ };
+
+ sch->q.qlen = choke_len(q) - q->holes;
+ opts = nla_nest_start(skb, TCA_OPTIONS);
+ if (opts == NULL)
+ goto nla_put_failure;
+
+ NLA_PUT(skb, TCA_RED_PARMS, sizeof(opt), &opt);
+ return nla_nest_end(skb, opts);
+
+nla_put_failure:
+ nla_nest_cancel(skb, opts);
+ return -EMSGSIZE;
+}
+
+static int choke_dump_stats(struct Qdisc *sch, struct gnet_dump *d)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct tc_red_xstats st = {
+ .early = q->stats.prob_drop + q->stats.forced_drop,
+ .pdrop = q->stats.pdrop,
+ .other = q->stats.other,
+ .marked = q->stats.prob_mark + q->stats.forced_mark,
+ };
+
+ return gnet_stats_copy_app(d, &st, sizeof(st));
+}
+
+static void choke_destroy(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ choke_free(q->tab);
+}
+
+static struct Qdisc_ops choke_qdisc_ops __read_mostly = {
+ .id = "choke",
+ .priv_size = sizeof(struct choke_sched_data),
+
+ .enqueue = choke_enqueue,
+ .dequeue = choke_dequeue,
+ .peek = qdisc_peek_head,
+ .drop = choke_drop,
+ .init = choke_init,
+ .destroy = choke_destroy,
+ .reset = choke_reset,
+ .change = choke_change,
+ .dump = choke_dump,
+ .dump_stats = choke_dump_stats,
+ .owner = THIS_MODULE,
+};
+
+static int __init choke_module_init(void)
+{
+ return register_qdisc(&choke_qdisc_ops);
+}
+
+static void __exit choke_module_exit(void)
+{
+ unregister_qdisc(&choke_qdisc_ops);
+}
+
+module_init(choke_module_init)
+module_exit(choke_module_exit)
+
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: [PATCH 0/3] net: add device groups
From: jamal @ 2011-01-10 14:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294666875.3583.6.camel@jlt3.sipsolutions.net>
On Mon, 2011-01-10 at 14:41 +0100, Johannes Berg wrote:
> Can you explain the purpose of this? I'm wondering if it would make
> sense to automatically group all virtual interfaces belonging to a
> single 802.11 device, for instance.
It depends what you want to do with that grouping.
In a nutshell, this greatly reduces the amount of kernel-user netlink
traffic in presence of multi interfaces.
you can do things like:
ip link set dev ppp0 group 1
...
...
ip link set dev pppN group 1
ip link ls group 1
ip link set down group 1
ip link set mtu 512 group 1
etc
Although now that i am thinking of it,
I am not sure whether it would be a legit thing to change
the MAC address of a group of devices - we may need to put
some restrictions.
Note: this grouping thing can also be potentially used in
packet policies etc (but i dont want to distract the simple
requirement we have at the moment).
cheers,
jamal
^ permalink raw reply
* Re: [patch] phonet: some signedness bugs
From: Dan Carpenter @ 2011-01-10 14:01 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <201101100958.32549.remi.denis-courmont@nokia.com>
On Mon, Jan 10, 2011 at 09:58:32AM +0200, Rémi Denis-Courmont wrote:
> On Friday 07 January 2011 22:37:55 ext Dan Carpenter, you wrote:
> > Dan Rosenberg pointed out that there were some signed comparison bugs
> > in the phonet protocol.
>
> There are two ways to solve this: change *only* the proto_get function to use
> an unsigned parameter, or cast the protocol to unsigned in the comparison.
>
> As David pointed out, your patch breaks the socket() callback prototype.
>
Yes. I really appologize for that. I'll send version 2 with that create()
change dropped. It's not needed.
I would like to keep the change to phonet_proto_register() because the
check in there isn't right and it's similar to phonet_proto_get(). We
may as well keep phonet_proto_unregister() as well so it's symmetric.
Let me know if you disagree and I'll redo it.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Wolfgang Grandegger @ 2011-01-10 14:05 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: socketcan-core, netdev
In-Reply-To: <20110110133112.GA324@e-circ.dyndns.org>
On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
> Wolfgang,
>
> A few thoughts ...
>
> On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
>>>
>>> obj-y += usb/
>>> +obj-y += softing/
>>
>> Please use "obj-$(CONFIG_CAN_SOFTING)" here.
> As I explained, softing does not depend on softing_cs or vice versa,
> which makes "obj-$(CONFIG_CAN_SOFTING)" not right.
OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
the *real* user?
...
>>> + priv->can.ctrlmode_supported =
>>> + CAN_CTRLMODE_3_SAMPLES;/* | CAN_CTRLMODE_BERR_REPORTING */;
>>
>> Hm, any chance to support CAN_CTRLMODE_BERR_REPORTING? If not, please
>> remove the comment.
>
> I think I better try to write it properly without, and add error reporting
> later, after serious testing of the error reporting on a softing card.
OK, then just cleanup properly.
> The primary goal now is get this driver in mainline kernel since PCMCIA
> has been changing recently, and I found it hard to keep up. So, first things
> first ...
Fine for me. You can then add my:
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Thanks.
Wolfgang.
^ permalink raw reply
* [patch v2] phonet: some signedness bugs
From: Dan Carpenter @ 2011-01-10 14:06 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <201101100958.32549.remi.denis-courmont@nokia.com>
Dan Rosenberg pointed out that there were some signed comparison bugs
in the phonet protocol.
http://marc.info/?l=full-disclosure&m=129424528425330&w=2
The problem is that we check for array overflows but "protocol" is
signed and we don't check for array underflows. If you have already
have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
could cause an oops by mistake.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
v2: in v1 I changed pn_socket_create() but that change caused a
compiler warning. That part of the patch wasn't needed so I've just
dropped.
diff --git a/include/net/phonet/phonet.h b/include/net/phonet/phonet.h
index d5df797..5395e09 100644
--- a/include/net/phonet/phonet.h
+++ b/include/net/phonet/phonet.h
@@ -107,8 +107,8 @@ struct phonet_protocol {
int sock_type;
};
-int phonet_proto_register(int protocol, struct phonet_protocol *pp);
-void phonet_proto_unregister(int protocol, struct phonet_protocol *pp);
+int phonet_proto_register(unsigned int protocol, struct phonet_protocol *pp);
+void phonet_proto_unregister(unsigned int protocol, struct phonet_protocol *pp);
int phonet_sysctl_init(void);
void phonet_sysctl_exit(void);
diff --git a/net/phonet/af_phonet.c b/net/phonet/af_phonet.c
index fd95beb..1072b2c 100644
--- a/net/phonet/af_phonet.c
+++ b/net/phonet/af_phonet.c
@@ -37,7 +37,7 @@
/* Transport protocol registration */
static struct phonet_protocol *proto_tab[PHONET_NPROTO] __read_mostly;
-static struct phonet_protocol *phonet_proto_get(int protocol)
+static struct phonet_protocol *phonet_proto_get(unsigned int protocol)
{
struct phonet_protocol *pp;
@@ -458,7 +458,7 @@ static struct packet_type phonet_packet_type __read_mostly = {
static DEFINE_MUTEX(proto_tab_lock);
-int __init_or_module phonet_proto_register(int protocol,
+int __init_or_module phonet_proto_register(unsigned int protocol,
struct phonet_protocol *pp)
{
int err = 0;
@@ -481,7 +481,7 @@ int __init_or_module phonet_proto_register(int protocol,
}
EXPORT_SYMBOL(phonet_proto_register);
-void phonet_proto_unregister(int protocol, struct phonet_protocol *pp)
+void phonet_proto_unregister(unsigned int protocol, struct phonet_protocol *pp)
{
mutex_lock(&proto_tab_lock);
BUG_ON(proto_tab[protocol] != pp);
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Wolfgang Grandegger @ 2011-01-10 14:07 UTC (permalink / raw)
To: Kurt Van Dijck
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D2B1245.9060303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 01/10/2011 03:05 PM, Wolfgang Grandegger wrote:
> On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
>> Wolfgang,
>>
>> A few thoughts ...
>>
>> On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
>>>>
>>>> obj-y += usb/
>>>> +obj-y += softing/
>>>
>>> Please use "obj-$(CONFIG_CAN_SOFTING)" here.
>> As I explained, softing does not depend on softing_cs or vice versa,
>> which makes "obj-$(CONFIG_CAN_SOFTING)" not right.
>
> OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
> Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
> the *real* user?
>
> ...
>
>>>> + priv->can.ctrlmode_supported =
>>>> + CAN_CTRLMODE_3_SAMPLES;/* | CAN_CTRLMODE_BERR_REPORTING */;
>>>
>>> Hm, any chance to support CAN_CTRLMODE_BERR_REPORTING? If not, please
>>> remove the comment.
>>
>> I think I better try to write it properly without, and add error reporting
>> later, after serious testing of the error reporting on a softing card.
>
> OK, then just cleanup properly.
>
>> The primary goal now is get this driver in mainline kernel since PCMCIA
>> has been changing recently, and I found it hard to keep up. So, first things
>> first ...
>
> Fine for me. You can then add my:
>
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Is there a mailing list for the PCMCIA interface? If yes, please add it
to the CC as well.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 14:08 UTC (permalink / raw)
To: hadi; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294668021.6063.315.camel@mojatatu>
On Mon, 2011-01-10 at 09:00 -0500, jamal wrote:
> On Mon, 2011-01-10 at 14:41 +0100, Johannes Berg wrote:
>
> > Can you explain the purpose of this? I'm wondering if it would make
> > sense to automatically group all virtual interfaces belonging to a
> > single 802.11 device, for instance.
>
> It depends what you want to do with that grouping.
> In a nutshell, this greatly reduces the amount of kernel-user netlink
> traffic in presence of multi interfaces.
> you can do things like:
>
> ip link set dev ppp0 group 1
> ...
> ...
> ip link set dev pppN group 1
>
> ip link ls group 1
> ip link set down group 1
> ip link set mtu 512 group 1
> etc
Right, but where would you want to use it -- what's the use case right
now? Your ppp example here makes me think the use case is some PPP
endpoint server that has lots of these interfaces. It also means the
grouping is entirely user-space controlled. In this case, the idea of
automatically grouping based on the device structure seems pointless.
johannes
^ permalink raw reply
* Re: [patch] phonet: some signedness bugs
From: Rémi Denis-Courmont @ 2011-01-10 14:08 UTC (permalink / raw)
To: ext Dan Carpenter
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <20110110140141.GA2721@bicker>
On Monday 10 January 2011 16:01:41 ext Dan Carpenter, you wrote:
> I would like to keep the change to phonet_proto_register() because the
> check in there isn't right and it's similar to phonet_proto_get(). We
> may as well keep phonet_proto_unregister() as well so it's symmetric.
> Let me know if you disagree and I'll redo it.
Sounds sensible to me.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [patch v2] phonet: some signedness bugs
From: Rémi Denis-Courmont @ 2011-01-10 14:12 UTC (permalink / raw)
To: ext Dan Carpenter; +Cc: netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <20110110140658.GB2721@bicker>
On Monday 10 January 2011 16:06:58 ext Dan Carpenter, you wrote:
> Dan Rosenberg pointed out that there were some signed comparison bugs
> in the phonet protocol.
>
> http://marc.info/?l=full-disclosure&m=129424528425330&w=2
>
> The problem is that we check for array overflows but "protocol" is
> signed and we don't check for array underflows. If you have already
> have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
> could cause an oops by mistake.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: jamal @ 2011-01-10 14:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294668505.3583.9.camel@jlt3.sipsolutions.net>
On Mon, 2011-01-10 at 15:08 +0100, Johannes Berg wrote:
>
> Right, but where would you want to use it -- what's the use case right
> now? Your ppp example here makes me think the use case is some PPP
> endpoint server that has lots of these interfaces.
That was just an example because someone mentioned PPP earlier.
Originally, this came from someone (Octavian?) trying to setup
a gazillion netdevs for testing purposes and then needing to
do "ip link ls dummy*" which causes a gazillion messages between
kernel and user space and all the filtering of what dummy* being
done in user space.
> It also means the
> grouping is entirely user-space controlled. In this case, the idea of
> automatically grouping based on the device structure seems pointless.
You still havent said what you want this grouping for. What is your
use case? ;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 14:38 UTC (permalink / raw)
To: hadi; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294669450.6063.319.camel@mojatatu>
On Mon, 2011-01-10 at 09:24 -0500, jamal wrote:
> > It also means the
> > grouping is entirely user-space controlled. In this case, the idea of
> > automatically grouping based on the device structure seems pointless.
>
> You still havent said what you want this grouping for. What is your
> use case? ;->
I don't have a use case. I was just wondering if there's any benefit in
grouping virtual devices that belong to a single physical device, but I
suppose there isn't.
johannes
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 14:40 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D2B1245.9060303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Jan 10, 2011 at 03:05:57PM +0100, Wolfgang Grandegger wrote:
> On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
> > On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
> OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
> Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
> the *real* user?
>
Good point.
I will add in Kconfig:
config CAN_SOFTING_CS
tristate "Softing CAN pcmcia cards"
depends on PCMCIA
+ select CAN_SOFTING
---help---
Thanks,
Kurt
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Randy Dunlap @ 2011-01-10 15:50 UTC (permalink / raw)
To: christoph.paasch
Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <201101101244.24932.christoph.paasch@uclouvain.be>
On Mon, 10 Jan 2011 12:44:24 +0100 Christoph Paasch wrote:
>
> On Monday, January 10, 2011 wrote Alexey Dobriyan:
> > >> linux/percpu_counter.h (needed for percpu_counter_sum_positive)
> > >
> > > Yes.
> >
> > Currently code compiles fine, so necessary headers are in place,
> > so simply adding new headers doesn't help anything.
>
> I totally agree with you.
> However we need a consistent coding style.
>
> Or we just include the minimum necessary headers (as originally proposed by
> me).
> Or we include every header whose structs/functions are referenced.
>
> In my opinion the current "mixed" state is not ok, because some includes are
> there because there *are* references (even if these includes could be omitted,
> e.g., linux/list.h).
> Other includes (like linux/percpu_counter.h) are not there, because they are
> indirectly included by another header and thus the code compiles. Even if
> there are references.
> And there are no rules/guidelines to identify the headers that should be
> included and those that should not.
Documentation/SubmitChecklist, #1:
1: If you use a facility then #include the file that defines/declares
that facility. Don't depend on other header files pulling in ones
that you use.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Christoph Paasch @ 2011-01-10 16:24 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <20110110075032.e38955ef.rdunlap@xenotime.net>
On Monday, January 10, 2011 wrote Randy Dunlap:
> Documentation/SubmitChecklist, #1:
>
> 1: If you use a facility then #include the file that defines/declares
> that facility. Don't depend on other header files pulling in ones
> that you use.
Ok, great. That was the answer I was looking for.
So, there is a clear rule that defines the #include-policy.
Now, should the missing #include's be added, or not?
Alexey Dobriyan is against it, as he says in one of his previous mails.
And, I'm nearly sure that the rule is not respected in plenty of other files
of the Linux Kernel.
Cheers,
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Randy Dunlap @ 2011-01-10 16:30 UTC (permalink / raw)
To: christoph.paasch
Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <201101101724.46023.christoph.paasch@uclouvain.be>
On Mon, 10 Jan 2011 17:24:45 +0100 Christoph Paasch wrote:
>
> On Monday, January 10, 2011 wrote Randy Dunlap:
> > Documentation/SubmitChecklist, #1:
> >
> > 1: If you use a facility then #include the file that defines/declares
> > that facility. Don't depend on other header files pulling in ones
> > that you use.
> Ok, great. That was the answer I was looking for.
>
> So, there is a clear rule that defines the #include-policy.
>
> Now, should the missing #include's be added, or not?
>
> Alexey Dobriyan is against it, as he says in one of his previous mails.
> And, I'm nearly sure that the rule is not respected in plenty of other files
> of the Linux Kernel.
If a build fails on any $architecture due to a missing header file, then
the header file should be added.
If you just want to fix source files that are missing header files, then
the patches should be accepted, even if they are not "needed" in some
strong sense of that word.
Adding the header files adds documentation that some interface from that
header file is being used and it prevents failures that would happen
if an indirect #include were removed, so it's a good practice, but sure,
there are plenty of places that miss this. It was added as Rule #1
(explicity as Rule __#1__) due to so many build errors due to this
that were occurring in linux-next trees.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 0/3] iproute2: ip link: add support for network device groups
From: Stephen Hemminger @ 2011-01-10 16:47 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: netdev, jamal, Octavian Purdila
In-Reply-To: <1294659559-22648-1-git-send-email-ddvlad@rosedu.org>
On Mon, 10 Jan 2011 13:39:16 +0200
Vlad Dogaru <ddvlad@rosedu.org> wrote:
> 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.
>
> The patches use the IFLA_GROUP and IFLA_FILTERGROUP messages, for which
> I posted pathes in a different set.
>
>
> Vlad Dogaru (3):
> ip link: add support for setting device groups
> ip link: support listing devices by group
> ip link: support setting device parameters by group
>
> include/linux/if_link.h | 3 ++
> include/linux/netdevice.h | 2 +-
> include/utils.h | 3 +-
> ip/ipaddress.c | 14 +++++++++++
> ip/iplink.c | 54 +++++++++++++++++++++++++++++++++++++++++++-
> ip/link_veth.c | 3 +-
> 6 files changed, 74 insertions(+), 5 deletions(-)
I like the idea, but I wonder if we should take it farther?
Should it be hierarchal tree of groups?
Should slave devices (ppp, vlan, etc) be automatically assigned
to group of parent?
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: john stultz @ 2011-01-10 16:49 UTC (permalink / raw)
To: Kuwahara,T.
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <AANLkTikigXGSACF6R6kfNHyKZ7GFWrUrCMxygvL3fUC6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 2011-01-10 at 06:07 +0900, Kuwahara,T. wrote:
> On Sun, Jan 9, 2011 at 2:50 AM, Richard Cochran
> <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > we want to be able to jump the clock arbitrarily.
>
> Another problem remains: How do you deal with leap seconds? I mean,
> given that 1 minute is not always 60 seconds, then what time was it
> XXXXX seconds ago? Maybe some kind of lookup table is necessary, but
> in such case, isn't it a better choice just to use the
> clock_settime/settimeofday syscall?
Leapsecond processing is done via an absolute hrtimer. Thus when the
time offset is set, the hrtimers that should have expired will fire
(just like with settimeofday) and the adjustment will then be made.
thanks
-john
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Alexey Dobriyan @ 2011-01-10 17:02 UTC (permalink / raw)
To: Randy Dunlap; +Cc: christoph.paasch, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <20110110083024.ab3bad25.rdunlap@xenotime.net>
On Mon, Jan 10, 2011 at 6:30 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> If you just want to fix source files that are missing header files, then
> the patches should be accepted, even if they are not "needed" in some
> strong sense of that word.
This will create a lot of noise. As if we haven't seen enough before.
^ 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