In article <20041214164821.GM4126@gallia.cubidou.net>,
Quentin Garnier <cube@cubidou.net> wrote:
>-=-=-=-=-=-
>
>On Tue, Dec 14, 2004 at 04:11:02PM +0000, Christos Zoulas wrote:
>> In article <5F935DB2-4DE5-11D9-8566-000A957650EC@shagadelic.org>,
>> Jason Thorpe <thorpej@shagadelic.org> wrote:
>> >-=-=-=-=-=-
>> >
>> >
>> >On Dec 13, 2004, at 6:58 AM, Manuel Bouyer 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.
>> >
>> >How about using ifmedia to determine the link type to emulate in tun?
>> 
>> Yes, that would be best.
>> 
>> >I think it's silly to have tun and ethfoo in the tree... and I think 
>> >ethfoo is a bad name for something that's not merely an example.
>> 
>> I agree, and I would like to see tun enhanced to encapsulate ethfoo
>> (tap) functionality. Can someone summarize the options, their
>> advantages/disadvantages, and which OS does what so that we can
>> decide what to do?
>
>I'll work on adding tun functionality to ethfoo.
>
>As for what can be done when having an interface that does both:
>1. Don't bother and keep them separate.
>2. Let the creator of the interface configure it once in either modes.
>3. Let the administrator make the interface switch between either
>   modes.
>
>1 is what FreeBSD does.  Linux does 2 and OpenBSD 3.
>
>As for the means of changing mode, Linux does it through an ioctl(),
>the one that you're supposed to do to initialize the interface.  You
>cannot change the mode after that.
>
>OpenBSD uses the link0 flag, and the switching process destroys the
>existing interface and re-creates one with the new mode.
>
>I made some comments on that somewhere else in this thread.

I'd say "don't bother and keep them separate" (I agree with the
way it is done in FreeBSD).  They provide different functionality
and the fact that a lot of code can be shared in the driver is not
a good enough reason to expose this implementation detail to the
user. I find the ioctl and the destroy previous + create new confusing.

I would expect to be able to have tun0...tunn and tap0...tapn and those
should not interfere with each other.

christos