Hackers, here is small problem(?) with DEVFS and device nodes that reside outside of /dev directory. here is an example: recent patch for tap(4) added "cloning" feature. the tap(4) also implements support for vmnet device that required by VMWare port. however, vmnet device nodes reside in /compat/linux/dev. if you load if_tap module and try to access /dev/tap? device everything is working fine, but if you create device node *outside* of /dev directory and try to access it, *before* you access the same node under /dev, you will get "Device not configured". # pwd /root # mknod tap0 c 149 0 # kldload if_tap # cat tap0 cat: tap0: Device not configured # cat /dev/tap0 ^C # cat tap0 ^C # the same probably true for tun(4) device. is that a problem? is it the way it should work? thanks, max From: Doug Ambrisko Subject: Re: Anyone experience problems with the "tap" device in current? Doug Ambrisko wrote: > > Maksim Yevmenkin writes: > | Brooks Davis wrote: > | > > | > On Wed, Sep 12, 2001 at 04:59:16PM -0700, Doug Ambrisko wrote: > | > > I just tried using tap in current. In both cases I don't see the > | > > /dev/tapX devices with devfs and accessing it without devfs doesn't > | > > work reporting "Device not configured". I tried it as a module and > | > > built into the kernel. Does anyone have this working? > | > > | > With devfs, you just need to try opening the device and you'll get it if > | > it's not busy. You can also open /dev/tap and get an arbitrary one. > | > This is due to tun(4) style cloning code I committed recently. I'm not > | > actually sure this is the way we want to handle cloning hybrid devices, > | > but there is precident so I committed the patch. I think we may want to > | > move to a model were we use interface cloning rather then devfs cloning > | > because it will work in stable. > | > | patch was tested on -current as of Aug 31. everything was working for > | me. i'm upgrading my system now to test it. > > My mess up I forgot about the cloning changes, however, seems the minor > number for vmnet type devices changed: > > a21p% ls -l /compat/linux/dev/vmnet? > crw-r--r-- 1 root wheel 149, 0x00010001 Sep 5 17:11 /compat/linux/dev/vmnet1 > crw-r--r-- 1 root wheel 149, 0x00010002 Sep 5 19:37 /compat/linux/dev/vmnet2 > crw-r--r-- 1 root wheel 149, 0x00010003 Aug 9 13:58 /compat/linux/dev/vmnet3 > crw-r--r-- 1 root wheel 149, 0x00010004 Aug 13 14:02 /compat/linux/dev/vmnet4 > crw-r--r-- 1 root wheel 149, 0x00010005 Aug 10 11:31 /compat/linux/dev/vmnet5 > crw-r--r-- 1 root wheel 149, 0x00010006 Aug 30 10:22 /compat/linux/dev/vmnet6 > crw-r--r-- 1 root wheel 149, 0x00010007 Aug 30 10:22 /compat/linux/dev/vmnet7 > crw-r--r-- 1 root wheel 149, 0x00010008 Sep 5 17:22 /compat/linux/dev/vmnet8 > crw-r--r-- 1 root wheel 149, 0x00010009 Sep 5 16:57 /compat/linux/dev/vmnet9 > a21p% > > to: > > a2# ls -l /dev/vmnet? > crw------- 1 root wheel 149, 0x00800000 Sep 12 17:32 /dev/vmnet0 > crw------- 1 root wheel 149, 0x00800004 Sep 12 17:32 /dev/vmnet4 > crw------- 1 root wheel 149, 0x00800006 Sep 12 17:32 /dev/vmnet6 > crw------- 1 root wheel 149, 0x00800007 Sep 12 17:32 /dev/vmnet7 > a2# > > So for now I got around this via: > > a2# ls -l /compat/linux/dev/vmnet? > lrwxr-xr-x 1 root wheel 11 Sep 13 01:54 /compat/linux/dev/vmnet1 -> /dev/vmnet1 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:54 /compat/linux/dev/vmnet2 -> /dev/vmnet2 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:55 /compat/linux/dev/vmnet3 -> /dev/vmnet3 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:55 /compat/linux/dev/vmnet4 -> /dev/vmnet4 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:55 /compat/linux/dev/vmnet5 -> /dev/vmnet5 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:54 /compat/linux/dev/vmnet6 -> /dev/vmnet6 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:56 /compat/linux/dev/vmnet7 -> /dev/vmnet7 > lrwxr-xr-x 1 root wheel 11 Sep 13 01:56 /compat/linux/dev/vmnet8 -> /dev/vmnet8 > a2# > > Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
