From owner-freebsd-bugs Sun Mar 19 17: 0: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id D8F6B37B7E0 for ; Sun, 19 Mar 2000 17:00:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA85606; Sun, 19 Mar 2000 17:00:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Sun, 19 Mar 2000 17:00:02 -0800 (PST) Message-Id: <200003200100.RAA85606@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Brian Somers Subject: Re: kern/17494: Two issues with the tun device Reply-To: Brian Somers Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/17494; it has been noted by GNATS. From: Brian Somers To: scott_long@btc.adaptec.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: kern/17494: Two issues with the tun device Date: Mon, 20 Mar 2000 00:54:45 +0000 > 1. the ifnet structure for the tun device is not created at attach time like > it is for other network drivers. Instead, it is created when the device is > opened, if it hasn't already been created in a previous open. This behaviour > causes my program to not see the tun device unless a program like ppp(8) is > run first, which defeats one of the goals of this program: to control dialup > networking. Comparing code in if_[tun|ppp|sl|lo].c shows that all but tun > create the ifnet structure from within their respective attach routine. But > on the other hand, if_tun.c uses make_dev while the others do not. Making > if_tun.c resemble the others is a trivial task, but I am not sure what would > be lost by eliminating make_dev (which requires a dev_t argument that attach > cannot supply, if I understand things correctly). Interfaces are moving towards being a lot more dynamic than they have been in the past. This new behaviour of the tun device is IMHO the way forward rather than a problem that has to be fixed. The way things currently are, you don't even need a tun device specified in your kernel. The module is as functional and will create new interfaces and softcs as required. In the future, I would think it's likely that the last close() will remove the interface. Why does you program require the interfaces existence up front ? Surely this is where the problem lies ? -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message