On Wed, Nov 28, 2012 at 10:42 PM, Mark Kettenis <[email protected]> wrote: >> From: Mike Belopuhov <[email protected]> >> Date: Wed, 28 Nov 2012 22:21:07 +0100 >> >> On Wed, Nov 28, 2012 at 8:21 PM, Mark Kettenis <[email protected]> >> wrote: >> >> Date: Wed, 28 Nov 2012 17:39:24 +0100 >> >> From: Reyk Floeter <[email protected]> >> >> >> >> Hi, >> >> >> >> inspired by mikeb@'s clonable bpf patch, this slightly more complex >> >> diff implements clonable interface support to tun(4). >> >> >> >> The idea is to split the fixed relation between device minor number >> >> (/dev/tunX) and interface unit (ifconfig tunY). In difference to the >> >> current tun(4) implementation, opening /dev/tun0 will first do nothing >> >> and return an unuseable device. You first have to call the new >> >> TUNSIFUNIT to assign/request a specified interface unit. >> > >> > Why? Because people don't realize they need to run MAKEDEV to get >> > more than four tun(4) devices? >> > >> >> Drawback: This diff would require to patch all the existing users of >> >> /dev/tun* in ports and the tree to add the TUNSIFUNIT ioctl. The >> >> benefit is that you don't have to MAKEDEV all the tuns anymore and can >> >> open up to around 1024 active tun(4) interfaces (with the specinfo >> >> patch). >> > >> > That's a pretty big drawback. >> > >> >> third party software has to be patched anyways, since tun is not >> standard. > > But currently /dev/tunN is usable from any programming language that > that can do reads and writes. With Reyk's changes you need to do an > ioctl even for basic usage, which is at best quirky in languages other > than C/C++. That feels like a step backward to me.
sure, we can totally leave tun for legacy use in the shell scripts. so i guess reyk should go ahead and implement a dynamic tun interface (dun?) with whatever semantics we need and want.
