Subject: Re: Moving ethfoo in the main tree
To: Manuel Bouyer <>
From: Quentin Garnier <>
List: tech-kern
Date: 12/13/2004 16:44:40
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 13, 2004 at 03:58:54PM +0100, Manuel Bouyer wrote:
> On Mon, Dec 13, 2004 at 10:33:28AM +0100, wrote:
> > I believe my ethfoo device has reached the point where it is useful
> > enough (notably with qemu) it could be in the main part of tree, rather
> > than a not built LKM.  There are a few points I need to address before
> > that, though.
> I'd like too. I'll need it for Xen 2.0 domain0 support.
> See
> for the reasons why we need this :)

Well, one reason more to do that then.

> > First, naming convention.  'ethfoo' was fine while it was only an
> > example, do we want to keep it instead of the commonly accepted 'tap'?
> My idea was ethtun, but if tap is already used elsewhere, go for it.

Yes, OpenBSD, FreeBSD and Linux use 'tap'.

> > That leads to another question:  should I add a tun-like part to it
> > so it could replace tun(4), or should I merge it with tun?  I don't
> > think it really makes sense to have both around.
> I was also thinking about adding a link2 flag to tun(4) to turn on ethern=
> 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

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.


Quentin Garnier - -
"Commala-come-five! / Even when the shadows rise!
To see the world and walk the world / Makes ya glad to be alive."
Susannah's Song, The Dark Tower VI, Stephen King, 2004.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.6 (NetBSD)