Re: Anyone experience problems with the "tap" device in current?
Marcel Moolenaar 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? > > My guess is that the breakage is related to the recent commits > that were made to if_tap. VMWare doesn't work anymore on -current > because the NG modules aren't loaded. These, AFAICT, depend on > the device. > > So, at this time I can only acknowledge the breakage. I probably > won't have the time to suggest or implement fixes. the recent if_tap patch implements device cloning (a-la tun(4)). unfortunately i had to change vmnet device mask and that affects VMWare port because minor numbers for vmnet devices has changed. bottom line: in order to make vmnet working you need to change minor numbers for vmnet device nodes. another solution would be to link /dev/vmnet? to /compat/linux/dev/vmnet? port maintainer has been notified. i'm sorry for the trouble. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone experience problems with the "tap" device in current?
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? My guess is that the breakage is related to the recent commits that were made to if_tap. VMWare doesn't work anymore on -current because the NG modules aren't loaded. These, AFAICT, depend on the device. So, at this time I can only acknowledge the breakage. I probably won't have the time to suggest or implement fixes. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone experience problems with the "tap" device in current?
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. just cvsup'ed new sources and compiled/installed new kernel. everything seems to work fine. at least without DEVFS. i will do full buildword tomorrow and test more. thansk, max p.s. building DEVFS enabled kernel now To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone experience problems with the "tap" device in current?
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. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
