--ylS2wUBXLOxYXZFQ
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, cube@cubidou.net 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.
>=20
> I'd like too. I'll need it for Xen 2.0 domain0 support.
> See http://mail-index.netbsd.org/port-xen/2004/12/12/0002.html
> 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'?
>=20
> 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.
>=20
> I was also thinking about adding a link2 flag to tun(4) to turn on ethern=
et
> 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?

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"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.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQb246NgoQloHrPnoAQKSgwgAyIia5CHQUyyw1s4td7bRPfYi/RfZq9cN
/NnKhIhoeJ/8KOJQJD1P68/q1avKiJIo52L2mYIpkdr2Whow0vCZZQPESibiVJhs
qtRA9sciu1GBh9yulx84SQpGaWEltZJnw3d9uVN0cyzkPJLwJq+h5e4a4d9cI9Ay
mEZQ36BN3Q4KQn+ddzz3hfsI/rs0ndSKUTWtbDPrzTn5aHM248P77W2xx49fF1l+
KIVYjrMyk7kZWQrpBtdNenHBnWvK/XuqR4foee/vPZwcWH+GeV0hIB/XOHc4G88i
IBztVodfhB5BMNcUPiG1oFcH76YcAfEHT2VISaOQcvr7eajH6ITPiA==
=H4pl
-----END PGP SIGNATURE-----

--ylS2wUBXLOxYXZFQ--