From owner-freebsd-drivers@freebsd.org Fri Sep 4 20:38:03 2015 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A02049CBF7E for ; Fri, 4 Sep 2015 20:38:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E6A41628 for ; Fri, 4 Sep 2015 20:38:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B8E0DB945; Fri, 4 Sep 2015 16:38:01 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: freebsd-drivers@freebsd.org, Leonardo Fogel Subject: Re: Race conditions Date: Fri, 04 Sep 2015 13:37:59 -0700 Message-ID: <2149458.2Hg3JbBXY3@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150904193207.GK2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <1595067.LHJIsK18l7@ralph.baldwin.cx> <20150904193207.GK2072@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 Sep 2015 16:38:01 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 20:38:03 -0000 On Friday, September 04, 2015 10:32:07 PM Konstantin Belousov wrote: > On Fri, Sep 04, 2015 at 11:42:38AM -0700, John Baldwin wrote: > > Hmm, looking at /dev/ptmx, it handles this by not doing a clone on open, > > but instead using a d_fdopen routine and explicitly setting up the new > > file descriptor as if it had opened the equivalent named device. Perhaps > > that is what I should do instead in my tap change. If I go that route, > > then I think that fdevname/devname would already DTRT without needing a > > new cdevsw method. > > There is probably some fine difference between pts, which are typically > fully managed and configured by master using the file descriptor, and > cloned network interfaces, where you usually allow external processes to > do the work. But if it works for tap, great. In some cases though the external management is not that much to arrange. For my particular use case (multiple VMs) devd can autoconfigure new tap devices as they are created (add them to a global bridge interface) and bhyve just does operations on the fd it has opened. > Also, you should have noted D3557 (csw d_devname), just in case ? I did see the e-mail but have not (yet) looked in detail. -- John Baldwin