Subject: Re: Moving ethfoo in the main tree
To: Quentin Garnier <>
From: Manuel Bouyer <>
List: tech-kern
Date: 12/13/2004 16:49:06
On Mon, Dec 13, 2004 at 04:44:40PM +0100, Quentin Garnier wrote:
> > I was also thinking about adding a link2 flag to tun(4) to turn on ethernet
> > emulation. I don't know how this would play with the ethernet layer.
> > I think an ethernet device needs to be registered here at creation time,
> > and can't be attached/detached from the ethernet layer at a later time.
> > But I didn't look deeply at this.
> I was thinking on how to add tun functionality and what API to provide
> to access it.  OpenBSD, FreeBSD and Linux all have their own mechanism
> for that.
> FreeBSD took the easy way out: tun(4) and tap(4) are separate.  Period.
> OpenBSD uses a link flag to switch from a mode to the other, while
> Linux has an ioctl().
> But why would we need to switch?  In OpenBSD, making the switch
> re-creates the interface.  In Linux, you choose the type of the
> interface in the setting up ioctl call, and then you cannot change it.
> So I don't think there is a point in switching back and forth.
> Here's my idea of how things could be done.  Currently I have the whole
> space of minor numbers devoted to actual ethfoo interfaces, indexed by
> the number.  The exception is the cloner device, whose minor number is
> 0xfffff.
> I could simply part in half the minor number space between tun and tap
> interfaces, and have two cloners.  That way the code is shared, but you
> get two cloning interface and two cloning devices.
> Moreover, I would keep minor numbers starting at 0 for tun devices, and
> get tun major number for the merged ethfoo.  That way existing tun0,
> tun1 etc. devices found in /dev would still work as before.
> You would have tap, tap0, tap1, ... and tun, tun0, tun1, ... in /dev,
> with tap's minor being 0xfffff, tun's 0x7ffff, tap0's 0x80000 and
> tun0's 0.  That way you choose first what kind of device you want,
> then you open it.
> That way of doing it would make things much simpler.
> As I said, we also need an API to retrieve the name of the interface.
> Linux writes the name of the interface in the answer to the setting-up
> ioctl() call.  I don't know if FreeBSD has a specific API for that
> as qemu uses devname(), but our devname(3) is too weak for the dynamic
> aspect of such interfaces.  Another TUN* ioctl() would do just fine.
> Comments?

How would we create an interface of the desired type (i.e.
ifconfig foo1 create) before using it ?
In some cases, having the interface created when the application wants to
use it isn't the desired behavior, we want to application to use an
already-existing and configured interface.

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference