From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <yuanhan.liu@linux.intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id D0519374F
 for <dev@dpdk.org>; Wed, 21 Sep 2016 04:13:15 +0200 (CEST)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
 by orsmga101.jf.intel.com with ESMTP; 20 Sep 2016 19:13:14 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.30,371,1470726000"; d="scan'208";a="1059779167"
Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162])
 by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2016 19:13:14 -0700
Date: Wed, 21 Sep 2016 10:13:51 +0800
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "pmatilai@redhat.com" <pmatilai@redhat.com>
Message-ID: <20160921021351.GY23158@yliu-dev.sh.intel.com>
References: <1473948649-14169-1-git-send-email-keith.wiles@intel.com>
 <1474042933-33625-1-git-send-email-keith.wiles@intel.com>
 <20160920040528.GO23158@yliu-dev.sh.intel.com>
 <17C91FD1-D21A-49E3-B093-71AA5C1D79C6@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17C91FD1-D21A-49E3-B093-71AA5C1D79C6@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [dpdk-dev] [PATCH v2] drivers/net:new PMD using tun/tap host
 interface
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 02:13:16 -0000

On Wed, Sep 21, 2016 at 01:32:15AM +0000, Wiles, Keith wrote:
> The concern I am having is on my standard Ubuntu 16.04 system these errors do not appear.

Yes, that's really weird. To me, it's such a solid error that could be
triggered on all linux platforms.

Anyway, I saw you removed the <net/if.h> including in v3, which makes
my robot happy :)

> I would like to understand why they appeared on your system. The ifdef __linux__ must be enabled as the defines in the linux/if_tun.h file do not give an error. I did play with the headers already and removed the ifdef, but as I could not reproduce your build failure it did not trigger anything new.
> 
> I will look at it some more, but it does not make sense and I do want to make sure it works.
> 
> > 
> >> +#include <linux/if.h>
> >> +#include <linux/if_tun.h>
> >> +#include <linux/if_ether.h>
> >> +#else
> >> +#include <netinet/if_ether.h>
> >> +#endif
> >> +#include <fcntl.h>
> >> +
> >> +#include <poll.h>
> >> +
> >> +/* Linux based path to the TUN device */
> >> +#define TUN_TAP_DEV_PATH        "/dev/net/tun"
> > 
> > However, you hardcoded a linux only path here. While checking the code
> > from qemu, I saw that the path is actually different from different UNIX
> > variants, even for FreeBSD and NetBSD.
> 
> I only assumed this to work for Linux and not FreeBSD/NetBSD as the handling of the opens on the tun device are different then linux. I also only added it to the common_linux configuration file.

I didn't notice the common_linux file, but I have guessed so (that you
meant to enable linux only): the "ifdef __linux" stuff just confuses me
a bit.

	--yliu
> 
> > 
> >    [yliu@yliu-dev ~/qemu]$ grep -E "/dev/.*(tap|tun)" net/tap*.c
> >    net/tap-bsd.c:            snprintf(dname, sizeof dname, "/dev/tun%d", i);
> >    net/tap-bsd.c:            snprintf(dname, sizeof dname, "/dev/tap%d", i);
> >    net/tap-bsd.c:#define PATH_NET_TAP "/dev/tap"
> >    net/tap-linux.c:#define PATH_NET_TUN "/dev/net/tun"
> >    net/tap-solaris.c:    TFR(tap_fd = open("/dev/tap", O_RDWR, 0));
> >    ...
> > 
> > 	--yliu