From: Henrik N. <hn...@ma...> - 2001-05-20 12:40:45
|
Jeff Dike wrote: > If you want TUN/TAP that badly, look at arch/um/drivers/ethertap*, write up > equivalent tuntap* files, and send them to me. From the docs, it looks like > generic (non-persistent) TUN/TAP is basically the same as ethertap, so you can > copy the ethertap code (which is tiny anyway) and make the few changes needed > to deal with TUN/TAP. The only difference is in how you open the device. With ETHERTAP you open /dev/tapX, with TUN/TAP you open /dev/net/tun and then issue a ioctl for getting access to the specific TUN/TAP interface. For getting access to a persistent TUN/TAP device all you need is to specify the interface name. UML should not request the device to be persistent (this is the job of the host administrator) > It's different from everything else by using non-ethernet frames. Ethertap > gives me ethernet frames. The daemon uses ethernet frames, but is different > by requiring communication (with the daemon) that the other interfaces don't. Another interesting approach for UML would be to use TUN devices. Similar to TAP but without the ethernet frame. Ideal for "point-to-point" channels. Using TAP devices is mostly when you need ethernet, for example when bridging things together instead of using routing (proxy-arp is a form of routing). -- Henrik Nordstrom MARA Systems |