From patchwork Fri Dec 6 04:42:58 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 297571 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id F3D8C2C0082 for ; Fri, 6 Dec 2013 15:43:08 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752180Ab3LFEnG (ORCPT ); Thu, 5 Dec 2013 23:43:06 -0500 Received: from mail-pb0-f43.google.com ([209.85.160.43]:46191 "EHLO mail-pb0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751728Ab3LFEnB (ORCPT ); Thu, 5 Dec 2013 23:43:01 -0500 Received: by mail-pb0-f43.google.com with SMTP id rq2so344645pbb.16 for ; Thu, 05 Dec 2013 20:43:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-type:content-transfer-encoding; bh=yrEP29dtfyyuCoLKodSHVAE2TdcTuqhr5n4e22bHD7Y=; b=TKyLRBrhFcuwofZGx0gxWWJ1CgyX6x4MOj8JlSW/2kZbQyBVyZR8fS2MDxOdswdNJD Ufx8hOq1UfIa4WFsH0VJhtC+N9JFAXleDj7W1w022HeMFSSn+xlLzXdkgNUhEdr/Zp5V 8MGUaLa/Fbl7pw8Pslec0JMRuTjRrPnUfVnho6RgTHREfVtKmHQSW6Jz2HSnQi6GrhWu VT8EOhEO+nGuD7vSAIWdn5s+30f8JIEl1SHGGEKtuclgyIv7cKPwRINN+c4QKKh7zbYi HrwSOSbaKIZt+9UU+1Dz6w1n3x0BKoRCSOkPEE2hpaYkIgATrdeuShcdhbu5iM/aNEBK XjIA== X-Gm-Message-State: ALoCoQlwH4O6N6mrWkM5J5il14ZnQ3xiOkYxFRxvQLRXClqhfgYcWYyBhmN5r0wrQSi6kKJnKopo X-Received: by 10.68.130.169 with SMTP id of9mr1663378pbb.79.1386304981169; Thu, 05 Dec 2013 20:43:01 -0800 (PST) Received: from nehalam.linuxnetplumber.net (static-50-53-83-51.bvtn.or.frontiernet.net. [50.53.83.51]) by mx.google.com with ESMTPSA id ql10sm706305pbc.44.2013.12.05.20.43.00 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 05 Dec 2013 20:43:00 -0800 (PST) Date: Thu, 5 Dec 2013 20:42:58 -0800 From: Stephen Hemminger To: David Miller Cc: netdev@vger.kernel.org Subject: [PATCH net-next] tun: spelling fixes Message-ID: <20131205204258.5eb404b2@nehalam.linuxnetplumber.net> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Fix spelling errors in tun driver. Signed-off-by: Stephen Hemminger Acked-by: Jason Wang --- 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 --- a/drivers/net/tun.c 2013-12-05 14:47:25.820499591 -0800 +++ b/drivers/net/tun.c 2013-12-05 14:55:37.032476288 -0800 @@ -110,7 +110,7 @@ struct tap_filter { unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN]; }; -/* DEFAULT_MAX_NUM_RSS_QUEUES were choosed to let the rx/tx queues allocated for +/* DEFAULT_MAX_NUM_RSS_QUEUES were chosen to let the rx/tx queues allocated for * the netdevice to be fit in one page. So we can make sure the success of * memory allocation. TODO: increase the limit. */ #define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES @@ -119,7 +119,7 @@ struct tap_filter { #define TUN_FLOW_EXPIRE (3 * HZ) /* A tun_file connects an open character device to a tuntap netdevice. It - * also contains all socket related strctures (except sock_fprog and tap_filter) + * also contains all socket related structures (except sock_fprog and tap_filter) * to serve as one transmit queue for tuntap device. The sock_fprog and * tap_filter were kept in tun_struct since they were used for filtering for the * netdevice not for a specific queue (at least I didn't see the requirement for @@ -342,7 +342,7 @@ unlock: } /* We try to identify a flow through its rxhash first. The reason that - * we do not check rxq no. is becuase some cards(e.g 82599), chooses + * we do not check rxq no. is because some cards(e.g 82599), chooses * the rxq based on the txq where the last packet of the flow comes. As * the userspace application move between processors, we may get a * different rxq no. here. If we could not get rxhash, then we would @@ -531,7 +531,7 @@ static int tun_attach(struct tun_struct err = 0; - /* Re-attach the filter to presist device */ + /* Re-attach the filter to persist device */ if (!skip_filter && (tun->filter_attached == true)) { err = sk_attach_filter(&tun->fprog, tfile->socket.sk); if (!err) @@ -819,9 +819,9 @@ static void tun_poll_controller(struct n * Tun only receives frames when: * 1) the char device endpoint gets data from user space * 2) the tun socket gets a sendmsg call from user space - * Since both of those are syncronous operations, we are guaranteed + * Since both of those are synchronous operations, we are guaranteed * never to have pending data when we poll for it - * so theres nothing to do here but return. + * so there is nothing to do here but return. * We need this though so netpoll recognizes us as an interface that * supports polling, which enables bridge devices in virt setups to * still use netconsole