* Re: [PATCH 2/2] ipv4: factorize cache clearing for batched unregister operations
From: David Miller @ 2009-11-17 8:35 UTC (permalink / raw)
To: bcrl; +Cc: shemminger, opurdila, netdev, eric.dumazet
In-Reply-To: <20091117002238.GH12422@kvack.org>
From: Benjamin LaHaise <bcrl@lhnet.ca>
Date: Mon, 16 Nov 2009 19:22:38 -0500
> It's not possible to create more than a few thousand IPv6 interfaces in
> my tests with a 4GB vm. The culprit seems to be the per-cpu arrays for
> statistics using vmalloc() and wasting gobs of memory as a result (memory
> usage seems to be 10x per interface vs what IPv4 is using), but I haven't
> dug too deeply yet.
That definitely should be fixed.
^ permalink raw reply
* Re: [RFC] dev->refcnt long term holder
From: Herbert Xu @ 2009-11-17 8:37 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, shemminger, netdev
In-Reply-To: <20091117.003019.196504832.davem@davemloft.net>
On Tue, Nov 17, 2009 at 12:30:19AM -0800, David Miller wrote:
>
> 1) PHY events in most drivers are handled in softirq (NAPI ->poll())
> or a workqueue of some sort these days. If we can make all of
> the link state management softirq safe (it probably is, except
> for perhaps RTNL), these case can be done synchronously always.
I think one of the reasons it's done this way is to call the function
netdev_state_change which needs to be in process context to walk
through the notifier list and do all the calls.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 23/10]Optimize the upload speed for PPP connection.
From: fangxiaozhi 00110321 @ 2009-11-17 8:45 UTC (permalink / raw)
To: netdev, davem, william.allen.simpson
In-Reply-To: <fb8ed0e9a479.a479fb8ed0e9@huawei.com>
Dear All:
Excuse me, how about my patch now?
Will my patch be fixed in the newest kernel version? What version is it?
Best Regards,
Franko Fang
2009-11-17
----- 原邮件 -----
发件人: fangxiaozhi 00110321 <huananhu@huawei.com>
日期: 星期三, 十月 28日, 2009 下午3:30
主题: Re: PATCH 23/10]Optimize the upload speed for PPP connection.
收件人: davem@davemloft.net,william.allen.simpson@gmail.com
抄送: netdev@vger.kernel.org,kernel@vger.kernel.org,zihan@huawei.com, greg@kroah.com,haegar@sdinet.de
>
> Thanks your advice.
>
> But generally, PAGE_SIZE is 4096, whether it is too large or not?
>
> If PAGE_SIZE is really appropriate, then I can resubmit the patch.
>
> Thanks very much.
> ----- Original Message -----
> From: "David Miller" <davem@davemloft.net>
> To: <william.allen.simpson@gmail.com>
> Cc: <huananhu@huawei.com>; <netdev@vger.kernel.org>; <linux-
> kernel@vger.kernel.org>; <zihan@huawei.com>; <greg@kroah.com>;
> <haegar@sdinet.de>Sent: Saturday, October 24, 2009 9:46 PM
> Subject: Re: PATCH 23/10]Optimize the upload speed for PPP connection.
>
>
> > From: William Allen Simpson <william.allen.simpson@gmail.com>
> > Date: Fri, 23 Oct 2009 07:46:08 -0400
> >
> >> Concur. I'd go further than that, my code usually made room
> for at
> >> least
> >> a full MTU (MRU) with HDLC escaping. To minimize context switches,
> >> that
> >> should be 3014 ((1500 MRU + 2 FCS + 4 header) * 2 escapes + 2
> flags).>>
> >> Even in the old days, when memory was tight, context switches and
> >> interrupt
> >> time were more expensive, too. PPP is supposed to scale to OC-192.
> >
> > Actually I'd like to see ->obuf allocated externally and then
> > make it simply PAGE_SIZE.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> ******************************************************************************************
> This email and its attachments contain confidential information
> from HUAWEI, which is intended only for the person or entity whose
> address is listed above. Any use of the information contained here
> in any way (including, but not limited to, total or partial
> disclosure, reproduction, or dissemination) by persons other than
> the intended recipient(s) is prohibited. If you receive this email
> in error, please notify the sender by phone or email
> immediately and delete it!
>
> *****************************************************************************************
^ permalink raw reply
* [PATCH] net: fix mdio section mismatch warning
From: Stephen Rothwell @ 2009-11-17 8:47 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Laurent Pinchart, Paulius Zaleckas, Mark Ware
This fixes the following warning:
WARNING: drivers/net/phy/built-in.o(.devexit.text+0x70): Section mismatch in reference from the function .mdio_gpio_bus_destroy() to the function .devinit.text:.mdio_gpio_bus_deinit()
The function __devexit .mdio_gpio_bus_destroy() references
a function __devinit .mdio_gpio_bus_deinit().
This is often seen when error handling in the exit function
uses functionality in the init path.
The fix is often to remove the __devinit annotation of
.mdio_gpio_bus_deinit() so it may be used outside an init section.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/phy/mdio-gpio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 8659d34..3589713 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -139,7 +139,7 @@ out:
return NULL;
}
-static void __devinit mdio_gpio_bus_deinit(struct device *dev)
+static void mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus->priv;
--
1.6.5.2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Subject: [PATCH 0/6] bna: Brocade 10Gb Ethernet device driver
From: Rasesh Mody @ 2009-11-17 8:57 UTC (permalink / raw)
To: netdev; +Cc: adapter_linux_open_src_team
From: Rasesh Mody <rmody@brocade.com>
This is patch 0/6 which contains the summary of changes we've
done in this perticular submission for Brocade's BR1010/BR1020
10Gb CEE capable ethernet adapter. Source is based against
net-next-2.6.
We wish this patch to be considered for inclusion in net-next-2.6.
We have addressed the following list of review comments:
1. Removed bfa_cb_queue macros and the corresponding file, #define WWN_NULL, Replaced MAC_ADDRLEN with ETH_ALEN
2. Removed lun_t
3. Removed references to LICENSE.bna
4. Using cpu_to_be64 in bna_dma_addr64() instead of swab64()
5. Addressed failure in case of "make allyesconfig"
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
0 files changed
^ permalink raw reply
* Re: Subject: [PATCH 1/6] bna: Brocade 10Gb Ethernet device driver
From: David Miller @ 2009-11-17 8:59 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <200911170830.nAH8UtQo010602@blc-10-10.brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Tue, 17 Nov 2009 00:30:55 -0800
> +#include <cna.h>
Using "cna.h" is more appropriate. "<cna.h>" assumes the
current working directory is in the header search path.
> +static uint bnad_msix = 1;
> +static uint bnad_small_large_rxbufs = 1;
> +static uint bnad_rxqsets_used;
> +static uint bnad_ipid_mode;
> +static uint bnad_vlan_strip = 1;
> +static uint bnad_txq_depth = BNAD_ENTRIES_PER_TXQ;
> +static uint bnad_rxq_depth = BNAD_ENTRIES_PER_RXQ;
> +static uint bnad_log_level ;
Many of these are a waste of space, on one or two counts.
Some of them are static settings that cannot be modified by
either module parameters or ethtool settings. Therefore they
are constant and should be entirely removed from the driver
and all conditionals on those values completely removed.
In the worst case "const" should be added to them so the compiler
can optimize everything away.
Many of them are also booleans, so even they did stay a more
appropriate type would be 'bool' which typically consumes less space
than 'int' and also communicates better the variable's use.
Overall, this is a very sloppy set of driver knobs.
> +static void
> +bnad_vlan_rx_register(struct net_device *netdev, struct vlan_group *grp);
...
> +static void
> +bnad_vlan_rx_kill_vid(struct net_device *netdev, unsigned short vid);
Don't chop things up like this just to abide by the "80 column line limit"
rule. This makes grepping produce useless results. If I grep for
"bnad_vlan_rx_kill_vid" the grep output won't show the function's
return type.
> +u32
> +bnad_get_msglevel(struct net_device *netdev)
One line please.
> +void
> +bnad_set_msglevel(struct net_device *netdev, u32 msglevel)
Same here. And for rest of driver.
> + BNA_ASSERT(wis <=
> + BNA_QE_IN_USE_CNT(&txqinfo->txq.q, txqinfo->txq.q.q_depth));
Please do not define your own assertion macros. We have an
incredibly complete set of BUG traps and warning producing
state tests. See "BUG_ON()", "WARN_ON()", "WARN()", etc.
Those macros should be used in favor of your's for many reasons,
the least of which is that WARN() is specifically tailored to
produce output that is parsable by kerneloops.org and other crash
dump analyzing tools.
> +static inline void
> +bnad_disable_txrx_irqs(struct bnad *bnad)
> +{
Is this performance critical? If not, why inline? Just drop
the inlines and let the compiler decide, we're not using 1990's
era compiler technology any more. :-)
> + if (sent) {
> + if (netif_queue_stopped(netdev) &&
> + netif_carrier_ok(netdev) &&
> + BNA_Q_FREE_COUNT(&txqinfo->txq) >=
> + BNAD_NETIF_WAKE_THRESHOLD) {
> + netif_wake_queue(netdev);
> + bnad->stats.netif_queue_wakeup++;
> + }
> + bna_ib_ack(bnad->priv, &txqinfo->ib, sent);
Is this driver multiqueue? It seems so.
Yet here you're only using global device queue flow control.
This means that if one TX queue fills up, it will stop packet
submission for all of your TX queues which is extremely
suboptimal.
Also the netif_carrier_ok() test is not correct here. The networking
core will stop TX submissions and synchronize the TX stream when the
carrier goes down. TX queue flow control is independant from carrier
handling.
> + prefetch(bnad);
> + prefetch(bnad->netdev);
Prefetching a variable then immediately dereferencing it is
completely pointless.
If you disagree show me a benchmark that shows otherwise.
> +static void
> +bnad_netpoll(struct net_device *netdev)
> +{
> + struct bnad *bnad = netdev_priv(netdev);
> + struct bnad_cq_info *cqinfo;
> + int i;
> +
> + if (!(bnad->config & BNAD_CF_MSIX)) {
> + disable_irq(bnad->pcidev->irq);
> + bnad_isr(bnad->pcidev->irq, netdev);
> + enable_irq(bnad->pcidev->irq);
> + } else {
> + for (i = 0; i < bnad->cq_num; i++) {
> + cqinfo = &bnad->cq_table[i];
> + bnad_disable_rx_irq(bnad, cqinfo);
> + bnad_poll_cq(bnad, cqinfo, BNAD_MAX_Q_DEPTH);
> + bnad_enable_rx_irq(bnad, cqinfo);
> + }
> + }
> +}
> +#endif
This is not correct. Even if you're not using BNAD_CF_MSIX
you are still using NAPI. So you should run the ISR and let
NAPI polling get scheduled.
Then bnad_poll_cq() is always running from NAPI ->poll() context
and therefore you don't need to use things like dev_kfree_skb_any()
et al. in there, you can use plain dev_kfree_skb() which is much
more efficient and correct.
> + tasklet_init(&bnad->tx_free_tasklet, bnad_tx_free_tasklet,
> + (unsigned long)bnad);
Using a tasklet for TX packet liberation is dubious at best. It's
just added overhead, scheduling yet another softirq from another
softirq (->poll() processing) when you can just invoke dev_kfree_skb()
directly.
> + if (bnad->priv) {
> +
> +
> + init_completion(&bnad->ioc_comp);
There's a lot of excessive spaces throughout the driver that looks
like this one, please clean them up. Anything more than one empty
line is likely too much.
^ permalink raw reply
* Re: Subject: [PATCH 2/6] bna: Brocade 10Gb Ethernet device driver
From: David Miller @ 2009-11-17 9:00 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <200911170830.nAH8Utli010605@blc-10-10.brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Tue, 17 Nov 2009 00:30:55 -0800
> +#include <bfa_timer.h>
> +#include <cs/bfa_debug.h>
More and more assumptions that the current directory is in
the header file search path. Use "dir/file.h" instead please.
^ permalink raw reply
* Re: Subject: [PATCH 3/6] bna: Brocade 10Gb Ethernet device driver
From: David Miller @ 2009-11-17 9:02 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <200911170830.nAH8UtrE010608@blc-10-10.brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Tue, 17 Nov 2009 00:30:55 -0800
> + return BFA_ROUNDUP(sizeof(struct bfa_cee_attr), BFA_DMA_ALIGN_SZ);
There is never a reason to invent your own infrastructure. We
have perfectly fine working ROUNDUP() et al. interfaces available
in the Linux kernel.
Please use them (see linux/kernel.h:DIV_ROUND_UP() and friends).
^ permalink raw reply
* Re: Subject: [PATCH 0/6] bna: Brocade 10Gb Ethernet device driver
From: David Miller @ 2009-11-17 9:03 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <200911170830.nAH8Ut5G010599@blc-10-10.brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Tue, 17 Nov 2009 00:30:55 -0800
> This is patch 0/6 which contains the summary of changes we've
> done in this perticular submission for Brocade's BR1010/BR1020
> 10Gb CEE capable ethernet adapter. Source is based against
> net-next-2.6.
I reviewed three of the 6 patches and that was exhausting enough
as-is. This driver still needs a bit more work, I'd say 2 or
3 more iterations if myself and others can muster the review
energy :-/
^ permalink raw reply
* Re: [PATCH 23/10]Optimize the upload speed for PPP connection.
From: David Miller @ 2009-11-17 9:08 UTC (permalink / raw)
To: huananhu; +Cc: netdev, william.allen.simpson
In-Reply-To: <f9f4a7c31b02f.1b02ff9f4a7c3@huawei.com>
From: fangxiaozhi 00110321 <huananhu@huawei.com>
Date: Tue, 17 Nov 2009 16:45:30 +0800
> Excuse me, how about my patch now?
>
> Will my patch be fixed in the newest kernel version? What version is it?
I said to make changes to your patch, and we'll look at the
updated version of the patch when you submit it.
The ball is in your court and has been so this entire time.
^ permalink raw reply
* [PATCH 17/11]Optimize the upload speed for PPP connection.
From: fangxiaozhi 00110321 @ 2009-11-17 9:19 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, william.allen.simpson
From: fangxiaozhi <huananhu@huawei.com>
1. This patch is based on the kernel of 2.6.32-rc4
2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
-----------------------------------------------------------------------------------------
--- a/drivers/net/ppp_async.c 2009-10-12 05:43:56.000000000 +0800
+++ b/drivers/net/ppp_async.c 2009-10-15 16:29:56.000000000 +0800
@@ -36,7 +36,7 @@
#define PPP_VERSION "2.4.2"
-#define OBUFSIZE 256
+#define OBUFSIZE 4096
/* Structure for storing local state. */
struct asyncppp {
******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
immediately and delete it!
*****************************************************************************************
^ permalink raw reply
* Re: [PATCH 23/10]Optimize the upload speed for PPP connection.
From: Franko Fang @ 2009-11-17 9:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, william.allen.simpson
In-Reply-To: <20091117.010821.159592646.davem@davemloft.net>
OK, I will resubmit it immediately.
Thanks.
----- Original Message -----
From: "David Miller" <davem@davemloft.net>
To: <huananhu@huawei.com>
Cc: <netdev@vger.kernel.org>; <william.allen.simpson@gmail.com>
Sent: Tuesday, November 17, 2009 5:08 PM
Subject: Re: [PATCH 23/10]Optimize the upload speed for PPP connection.
> From: fangxiaozhi 00110321 <huananhu@huawei.com>
> Date: Tue, 17 Nov 2009 16:45:30 +0800
>
>> Excuse me, how about my patch now?
>>
>> Will my patch be fixed in the newest kernel version? What version is it?
>
> I said to make changes to your patch, and we'll look at the
> updated version of the patch when you submit it.
>
> The ball is in your court and has been so this entire time.
^ permalink raw reply
* Re: [PATCH] e1000e: Fix usage under kexec
From: Stefan Assmann @ 2009-11-17 9:21 UTC (permalink / raw)
To: Sven Anders; +Cc: netdev
In-Reply-To: <4AF87AB1.1070603@anduras.de>
On 09.11.2009 21:25, Sven Anders wrote:
> Hello!
>
> We're experiencing the following problem:
>
> We start a minimal linux system, prepare the system and start the
> final system via kexec.
> On two different systems (one with a 82573 and one with a 82574),
> the driver cannot initialize the network hardware, because the PHY
> is not recognized.
>
> We get the following error:
> e1000e: probe of 0000:02:00.0 failed with error -2
Hi Sven,
have a look at the following thread, it seems very similar.
http://kerneltrap.org/mailarchive/linux-netdev/2009/3/7/5114394
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles Cachera
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: David Miller @ 2009-11-17 9:22 UTC (permalink / raw)
To: huananhu; +Cc: netdev, linux-kernel, william.allen.simpson
In-Reply-To: <faf197be196ee.196eefaf197be@huawei.com>
From: fangxiaozhi 00110321 <huananhu@huawei.com>
Date: Tue, 17 Nov 2009 17:19:02 +0800
> From: fangxiaozhi <huananhu@huawei.com>
> 1. This patch is based on the kernel of 2.6.32-rc4
> 2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
> Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Your patch is broken, please don't wate my time like this.
+ git apply --check --whitespace=error-all diff
error: patch failed: drivers/net/ppp_async.c:36
error: drivers/net/ppp_async.c: patch does not apply
^ permalink raw reply
* Re: Shared i2c adapter locking
From: Jean Delvare @ 2009-11-17 9:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Ben Hutchings, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mika Kuoppala, Linux I2C
In-Reply-To: <20091117193313.b750804e.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
Hi Stephen,
On Tue, 17 Nov 2009 19:33:13 +1100, Stephen Rothwell wrote:
> Hi Jean,
>
> On Thu, 5 Nov 2009 15:07:15 +0100 Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> >
> > > Presumably this is meant for net-next-2.6, and you'll implement
> >
> > Actually I meant to push this to Linus immediately, through my i2c
> > tree. This is essentially a no-op: the binary code will be the same as
> > before the patch, so guaranteed to be safe, and this will solve
> > conflicts in linux-next.
>
> Any word on this?
Haven't you read this:
http://www.spinics.net/lists/linux-next/msg07839.html
and the 3 following posts?
If you did and something is still not clear, please let me know. My
understanding is that the action token is in David's hands now.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: William Allen Simpson @ 2009-11-17 10:20 UTC (permalink / raw)
To: huananhu; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20091117.012248.86306050.davem@davemloft.net>
David Miller wrote:
> Your patch is broken, please don't wate my time like this.
>
> + git apply --check --whitespace=error-all diff
> error: patch failed: drivers/net/ppp_async.c:36
> error: drivers/net/ppp_async.c: patch does not apply
>
What David may have meant, had he followed Documentation/ManagementStyle
or had any project management skills what-so-ever, is that you need to
follow Documentation/SubmittingPatches more carefully.
Look at 15) The canonical patch format
[PATCH 17/11] makes no sense, you don't have 11 patches, and the 17th
patch of 11 can never exist.
Need a better "subsystem: summary phrase", perhaps
"net: PPP buffer too small for higher speed connections"
A marker line containing simply "---".
And your trailer boilerplate badly breaks the system, because it's
missing the SMTP email standard "--" line in front of it.
You'll get nicer formatting with 'git format-patch -o ~ HEAD~1' after you
do a 'git commit -a' on your git tree.
It takes some time, even for a simple 1 line fix like this....
Hope that helps.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: William Allen Simpson @ 2009-11-17 10:41 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, joe
In-Reply-To: <20091116.191522.178198674.davem@davemloft.net>
David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 16 Nov 2009 23:26:04 +0100
>
>> So adding DATA to SYN packets might be problematic for part of our tcp stack.
>
But is outside the scope of anything in this part 1 patch series.
Of course, part 2 will dispense with the request_sock entirely....
> I can almost guarentee it won't work. For one thing getting a SACK
> response to a SYN+DATA packet will explode quite nicely for one thing.
>
Sounds like a lack of error handling to me.... Never trust that sensible
data will appear from the network!
> A lot of the other retransmit queue handling would need to be audited
> as well. So much code assumes that if we see sent data in the
> retransmit queue, there won't be SYN or SYN+ACK things in there to
> contend with.
>
Well then, it's a darn tootin' good thing that the code in part 1g doesn't
send SYNACK data in the retransmit queue, and the code in 1d (here) doesn't
include the SYNACK data in the tcp_minisocks.c clone. The prominent
comment might have been a sign to the careful reviewer:
+ * as it differs for each connection. There is no need to
+ * copy any s_data_payload stored at the original socket.
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: Jarek Poplawski @ 2009-11-17 11:14 UTC (permalink / raw)
To: William Allen Simpson; +Cc: huananhu, David Miller, netdev, linux-kernel
In-Reply-To: <4B0278D9.6030806@gmail.com>
On 17-11-2009 11:20, William Allen Simpson wrote:
> David Miller wrote:
>> Your patch is broken, please don't wate my time like this.
>>
>> + git apply --check --whitespace=error-all diff
>> error: patch failed: drivers/net/ppp_async.c:36
>> error: drivers/net/ppp_async.c: patch does not apply
>>
> What David may have meant, had he followed Documentation/ManagementStyle
> or had any project management skills what-so-ever, is that you need to
> follow Documentation/SubmittingPatches more carefully.
I think this time it was only about a missing tab ;-)
Jarek P.
>
> Look at 15) The canonical patch format
>
> [PATCH 17/11] makes no sense, you don't have 11 patches, and the 17th
> patch of 11 can never exist.
>
> Need a better "subsystem: summary phrase", perhaps
> "net: PPP buffer too small for higher speed connections"
>
> A marker line containing simply "---".
>
> And your trailer boilerplate badly breaks the system, because it's
> missing the SMTP email standard "--" line in front of it.
>
> You'll get nicer formatting with 'git format-patch -o ~ HEAD~1' after you
> do a 'git commit -a' on your git tree.
>
> It takes some time, even for a simple 1 line fix like this....
>
> Hope that helps.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* net-next-2.6 compilation errors: missing wireless/i82593.h
From: William Allen Simpson @ 2009-11-17 11:34 UTC (permalink / raw)
To: Linux Kernel Developers; +Cc: Linux Kernel Network Developers, John W. Linville
For the past 9-10 days, net-next-2.6 has failed to compile. In addition to
the errors and warnings already reported here last week, since Nov 12th
there has been another missing file. I kept hoping it was temporary, but
no joy.
/home/administer/net-next-2.6/drivers/net/znet.c:107:29: error: wireless/i82593.h: No such file or directory
/home/administer/net-next-2.6/drivers/net/znet.c:133: error: field ‘i593_init’ has incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_set_multicast_list’:
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:235: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:247: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:248: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:249: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:250: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:251: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:254: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:255: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:256: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:259: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:260: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:261: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:262: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:265: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:266: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:267: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:268: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:271: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:274: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:277: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:278: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:281: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:282: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:283: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:284: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:285: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:286: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:289: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:290: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:291: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:294: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:297: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:298: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:299: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:300: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:301: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:302: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:303: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:304: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:307: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:310: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:311: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:312: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:315: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:316: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:317: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:318: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:319: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:320: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:323: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:324: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:325: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:326: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:327: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:328: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:329: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:330: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:333: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:334: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:340: error: dereferencing pointer to incomplete type
/home/administer/net-next-2.6/drivers/net/znet.c:345: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:346: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:346: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:346: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:347: error: invalid application of ‘sizeof’ to incomplete type ‘struct i82593_conf_block’
/home/administer/net-next-2.6/drivers/net/znet.c:348: error: ‘OP0_CONFIGURE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:348: error: (Each undeclared identifier is reported only once
/home/administer/net-next-2.6/drivers/net/znet.c:348: error: for each function it appears in.)
/home/administer/net-next-2.6/drivers/net/znet.c:348: error: ‘CR0_CHNL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_tx_timeout’:
/home/administer/net-next-2.6/drivers/net/znet.c:512: error: ‘CR0_STATUS_0’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:514: error: ‘CR0_STATUS_1’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:516: error: ‘CR0_STATUS_2’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:518: error: ‘CR0_STATUS_3’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:522: error: ‘TX_LOST_CRS’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:525: error: ‘OP0_RESET’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_send_packet’:
/home/administer/net-next-2.6/drivers/net/znet.c:549: error: ‘CR0_STATUS_0’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:583: error: ‘OP0_TRANSMIT’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:583: error: ‘CR0_CHNL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_interrupt’:
/home/administer/net-next-2.6/drivers/net/znet.c:612: error: ‘CR0_STATUS_0’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:617: error: ‘CR0_STATUS_1’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:619: error: ‘CR0_STATUS_2’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:621: error: ‘CR0_STATUS_3’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:626: error: ‘SR0_INTERRUPT’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:631: error: ‘SR0_EVENT_MASK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:631: error: ‘SR0_TRANSMIT_DONE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:632: error: ‘SR0_RETRANSMIT_DONE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:633: error: ‘SR0_TRANSMIT_NO_CRC_DONE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:638: error: ‘TX_OK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:640: error: ‘TX_NCOL_MASK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:642: error: ‘TX_LOST_CTS’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:642: error: ‘TX_LOST_CRS’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:644: error: ‘TX_UND_RUN’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:646: error: ‘TX_HRT_BEAT’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:648: error: ‘TX_MAX_COL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:666: error: ‘SR0_RECEPTION’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:667: error: ‘SR0_STOP_REG_HIT’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:671: error: ‘CR0_INT_ACK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_rx’:
/home/administer/net-next-2.6/drivers/net/znet.c:688: error: ‘CR0_STATUS_2’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:747: error: ‘RX_RCV_OK’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:749: error: ‘RX_CRC_ERR’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:750: error: ‘RX_ALG_ERR’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:756: error: ‘RX_OVRRUN’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:758: error: ‘RX_SRT_FRM’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘znet_close’:
/home/administer/net-next-2.6/drivers/net/znet.c:814: error: ‘OP0_RESET’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘hardware_init’:
/home/administer/net-next-2.6/drivers/net/znet.c:859: error: ‘OP0_RESET’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:885: error: ‘OP0_CONFIGURE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:885: error: ‘CR0_CHNL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:893: error: ‘OP0_IA_SETUP’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:898: error: ‘OP0_RCV_ENABLE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c: In function ‘update_stop_hit’:
/home/administer/net-next-2.6/drivers/net/znet.c:904: error: ‘OP0_SWIT_TO_PORT_1’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:904: error: ‘CR0_CHNL’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:907: error: ‘CR1_STOP_REG_UPDATE’ undeclared (first use in this function)
/home/administer/net-next-2.6/drivers/net/znet.c:909: error: ‘OP1_SWIT_TO_PORT_0’ undeclared (first use in this function)
make[3]: *** [drivers/net/znet.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [drivers/net] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2
^ permalink raw reply
* Re: net-next-2.6 compilation errors: missing wireless/i82593.h
From: David Miller @ 2009-11-17 11:44 UTC (permalink / raw)
To: william.allen.simpson; +Cc: linux-kernel, netdev, linville
In-Reply-To: <4B028A37.1010202@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Tue, 17 Nov 2009 06:34:15 -0500
> For the past 9-10 days, net-next-2.6 has failed to compile. In
> addition to the errors and warnings already reported here last week,
Those seemed to be for Android drivers and such, so I hope you
reported those failures to the driver maintainers as well as
linux-kernel.
For the time being could you just disable those drivers in your
build just to get work done or do you absolutely need them?
> since Nov 12th there has been another missing file. I kept hoping
> it was temporary, but no joy.
>
> /home/administer/net-next-2.6/drivers/net/znet.c:107:29: error:
> wireless/i82593.h: No such file or directory
That header file got moved out to drivers/staging along with the
wavelan driver.
The header file should instead be moved to, perhaps, include/linux
while there are still other users of it.
That's incredibly clumsy what drivers/net/znet.c is doing.
John please fix this up, thanks!
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: William Allen Simpson @ 2009-11-17 11:49 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: huananhu, David Miller, netdev, linux-kernel
In-Reply-To: <20091117111454.GA8341@ff.dom.local>
Jarek Poplawski wrote:
> On 17-11-2009 11:20, William Allen Simpson wrote:
>> David Miller wrote:
>>> Your patch is broken, please don't wate my time like this.
>>>
>>> + git apply --check --whitespace=error-all diff
>>> error: patch failed: drivers/net/ppp_async.c:36
>>> error: drivers/net/ppp_async.c: patch does not apply
>>>
>> What David may have meant, had he followed Documentation/ManagementStyle
>> or had any project management skills what-so-ever, is that you need to
>> follow Documentation/SubmittingPatches more carefully.
>
> I think this time it was only about a missing tab ;-)
>
In his inimitable inimical manner, comprehensively comprehensible. ;-)
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: David Miller @ 2009-11-17 11:49 UTC (permalink / raw)
To: william.allen.simpson; +Cc: huananhu, netdev, linux-kernel
In-Reply-To: <4B0278D9.6030806@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Tue, 17 Nov 2009 05:20:09 -0500
> What David may have meant, had he followed
> Documentation/ManagementStyle or had any project management skills
> what-so-ever, is that you need to follow
> Documentation/SubmittingPatches more carefully.
Are personal attacks on me really necessary?
Do you want me to look closely at your patches with a high priority
when you submit them for inclusion? If so, then you may want to
think twice about saying things like this.
You may be right, but that doesn't matter if you're interested in
working together with me in the future. There are diplomatic ways to
do everything, and this wasn't one of those ways.
^ permalink raw reply
* Re: Shared i2c adapter locking
From: David Miller @ 2009-11-17 11:51 UTC (permalink / raw)
To: khali
Cc: sfr, bhutchings, netdev, linux-next, linux-kernel, mika.kuoppala,
linux-i2c
In-Reply-To: <20091117103554.03971b2f@hyperion.delvare>
From: Jean Delvare <khali@linux-fr.org>
Date: Tue, 17 Nov 2009 10:35:54 +0100
> If you did and something is still not clear, please let me know. My
> understanding is that the action token is in David's hands now.
So what exactly do I need to do?
All I see that needs to happen is to pull from Linus's tree into
net-2.6
But frankly I don't see how that helps resolve anything in linux-next
since Stephen starts with Linus's tree then pulls in everyone's work.
Or is that pull necessary so that some other patch can be applied
to net-2.6 or similar?
^ permalink raw reply
* Re: updates to the mscan-driver in net-next
From: David Miller @ 2009-11-17 11:54 UTC (permalink / raw)
To: w.sang; +Cc: netdev, linuxppc-dev, socketcan-core, grant.likely, wg
In-Reply-To: <1258412274-14686-1-git-send-email-w.sang@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Mon, 16 Nov 2009 23:57:43 +0100
> here are the patches which fix the issues for the mscan & mpc52xx_can drivers
> raised by Wolfgang Grandegger and Grant Likely. They are based on the initial
> version of the drivers I sent a few days ago. Devicetree-discuss has been added
> for the property changes. I will also update my branch on pengutronix.de
> tomorrow, I seem to have issues when trying that from home :(^
All applied to net-next-2.6, thank you.
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: Franko Fang @ 2009-11-17 11:54 UTC (permalink / raw)
To: Jarek Poplawski, William Allen Simpson; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20091117111454.GA8341@ff.dom.local>
Well, yes, I think that it misses the tab.
I will update the patch, and resubmit it again.
Thanks for all .
----- Original Message -----
From: "Jarek Poplawski" <jarkao2@gmail.com>
To: "William Allen Simpson" <william.allen.simpson@gmail.com>
Cc: <huananhu@huawei.com>; "David Miller" <davem@davemloft.net>; <netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org>
Sent: Tuesday, November 17, 2009 7:14 PM
Subject: Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
> On 17-11-2009 11:20, William Allen Simpson wrote:
>> David Miller wrote:
>>> Your patch is broken, please don't wate my time like this.
>>>
>>> + git apply --check --whitespace=error-all diff
>>> error: patch failed: drivers/net/ppp_async.c:36
>>> error: drivers/net/ppp_async.c: patch does not apply
>>>
>> What David may have meant, had he followed Documentation/ManagementStyle
>> or had any project management skills what-so-ever, is that you need to
>> follow Documentation/SubmittingPatches more carefully.
>
> I think this time it was only about a missing tab ;-)
>
> Jarek P.
>
>>
>> Look at 15) The canonical patch format
>>
>> [PATCH 17/11] makes no sense, you don't have 11 patches, and the 17th
>> patch of 11 can never exist.
>>
>> Need a better "subsystem: summary phrase", perhaps
>> "net: PPP buffer too small for higher speed connections"
>>
>> A marker line containing simply "---".
>>
>> And your trailer boilerplate badly breaks the system, because it's
>> missing the SMTP email standard "--" line in front of it.
>>
>> You'll get nicer formatting with 'git format-patch -o ~ HEAD~1' after you
>> do a 'git commit -a' on your git tree.
>>
>> It takes some time, even for a simple 1 line fix like this....
>>
>> Hope that helps.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ 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