On 11/29/2012 01:33 PM, Reyk Floeter wrote: > On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov <[email protected]> wrote: >>> 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. > > Or even better duh? ;-) I wrote this diff because I wanted to > experiment with clonable device nodes, I still don't like the fact > that you have to MAKEDEV a device per dynamic interface, and because > it adds some extra flexibility. But it doesn't have to go anywhere, I > didn't even waste much time with writing it yesterday in the > afternoon. > > btw., I like C and it is still my favorite language (sorry, CS > people). But it shouldn't be a problem to do simple ioctls with most > other languages except shell scripts. > > #!/usr/bin/perl > require "sys/ioctl.ph"; > $TUNSIFUNIT = _IOC(&IOC_INOUT, ord('t'), 90, 4); > open(TUN0, "+</dev/tun0") or die "open"; > ioctl(TUN0, $TUNSIFUNIT, $unit = pack("i", -1)) or die "ioctl $!"; > print "Returned: tun".unpack("i", $unit)."\n"; > close(TUN0); > > reyk >
I like cloning devices. But instead of needing an ioclt(2), wouldn't it be simpler to adapt the SVR4 API where the first parameter of cdevsw open() functions is an 'dev_t *dev'. Thus the open() routine can automatically do the cloning (or maybe not if minor is > 0) by returning the device-Id of the cloned instance. and there is no need for using additional ioctl(2)s. Of course it requires a one-time API change with large impact. Gerhard
