From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 19:24:04 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DA2106568D; Fri, 14 Aug 2009 19:24:04 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 24CE08FC51; Fri, 14 Aug 2009 19:24:04 +0000 (UTC) Received: from [172.31.193.10] (cpe-069-134-110-200.nc.res.rr.com [69.134.110.200]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n7EJO3sj017093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 15:24:03 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n7EJO3sj017093 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1250277843; bh=gfI5I7KYjEsR9vQ5Y6N4/d6DpztiMclMfQfmNUEKVPw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kQQrTBSUYmdR3fKiOZyi37s2jGMMrvSWS7rEJHtguIZMbL7FGc/y1A9ATHjUlYnZV nUVk8sBKqbCGVS//dyHT+fU09erNGpOBhTsaM9bhDX5pOFCwkUO3XgZUTq7Ba9rDxG KcxQX8AOGSn91vlyKlXy1pS6a3ZxMtypkljp0Pw0= Message-ID: <4A85B9CD.4050802@cs.duke.edu> Date: Fri, 14 Aug 2009 15:23:57 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Robert Watson References: <4A857D16.9070403@cs.duke.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:24:04 -0000 Robert Watson wrote: > On Fri, 14 Aug 2009, Andrew Gallatin wrote: > >> I've been porting a closed-source driver to FreeBSD 8 from FreeBSD >> 5/6/7. It use the dev_clone() eventhandler to mimic linux-like open >> semantics (for linux binary compat). > > No particular experience with unloading cloning stuff, but have you > noticed that in 8.x we now have per-file descriptor device state? This > is often the semantics people actually want, rather than cloning. See > devfs_set_cdevpriv(9) for details -- there are several synthetic devices > in the tree that use it now (although some of them do too much > error-checking, and should assert rather than return errors, I think). Unfortunately, I think I still need device cloning. The linux semantics are to open /dev/mx0, then call an ioctl to set the device private state. This gets set (in linux) in the "struct file *" ->private_data field. So multiple processes can open /dev/mx0, and they all have different private data. FWIW: >> I'm assuming these files are lingering because clone_cleanup() >> (called at device detach) is not cleaning up these lingering >> device nodes. I've tried writing a dtrace script to trace >> clone_cleanup. But since that happens from device detach, >> dtrace doesn't work (blocks driver unload). I've also tried >> setting a breakpoint in ddb(), but the breakpoint seems to >> be ignored (other breakpoints work fine, which is odd). I think ddb wasn't working because my kernel sources didn't quite match my running kernel. After a kernel & module rebuild, I can watch clone_cleanup(), and I see destroy_devl() get called. It calls devfs_destroy(), as well. The interesting thing is that if I run devd -D -d, and watch the events scroll by, I see the destruction of a device with a null name. Eg: Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev= Processing notify event <...> If I do the same thing on 7.2, I see: Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=mx_fake.0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=mx_fake.0 Processing notify event So I wonder if the node is not getting removed because its name has gotten mangled somehow... Drew