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
Anyone experience problems with the "tap" device in current?
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? a2# ls /dev acd0a cuala1 pci ttyld1 ttyvb acd0c fd ppi0ttyp0 ttyvc ad0 fd0 ptyp0 ttyv0 ttyvd ata io random ttyv1 ttyve bpf0kbd0stderr ttyv2 ttyvf console klogstdin ttyv3 urandom consolectl kmemstdout ttyv4 usb cttylog sysmousettyv5 usb0 cuaa0 lpt0ttyd0 ttyv6 vga cuaa1 lpt0.ctlttyd1 ttyv7 zero cuaia0 mdctl ttyid0 ttyv8 cuaia1 mem ttyid1 ttyv9 cuala0 nullttyld0 ttyva a2# df /dev Filesystem 1K-blocks UsedAvail Capacity Mounted on devfs 110 100%/dev a2# kldstat Id Refs AddressSize Name 16 0xc000 4000 kernel 21 0xc13b1000 14000linux.ko 31 0xc13eb000 4000 if_tap.ko a2# Thanks, Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
