From owner-freebsd-arch@FreeBSD.ORG Mon May 5 18:26:59 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C00106566C for ; Mon, 5 May 2008 18:26:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CBB928FC16 for ; Mon, 5 May 2008 18:26:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id 3C0051A4D80; Mon, 5 May 2008 11:26:59 -0700 (PDT) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m45IQjdo069338; Mon, 5 May 2008 14:26:45 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Kostik Belousov Date: Mon, 5 May 2008 11:56:14 -0400 User-Agent: KMail/1.9.7 References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805050939.42425.jhb@freebsd.org> <20080505142051.GS18958@deviant.kiev.zoral.com.ua> In-Reply-To: <20080505142051.GS18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805051156.14706.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 05 May 2008 14:26:45 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7035/Mon May 5 13:47:07 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 18:27:00 -0000 On Monday 05 May 2008 10:20:51 am Kostik Belousov wrote: > On Mon, May 05, 2008 at 09:39:42AM -0400, John Baldwin wrote: > > On Sunday 04 May 2008 01:10:02 pm Kostik Belousov wrote: > > > Since the review for the clone-at-open patch (fdclone) posted some time ago > > > mostly says that it would be better to implement per-file private data > > > instead, I produced the patch along this line, > > > > > > The patch does not change the cdevsw ABI, instead, three new functions > > > nt devfs_get_cdevpriv(void **datap); > > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > > void devfs_clear_cdevpriv(void); > > > are provided for manipulation of the per-file private data. > > > > > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > > > which is used to initiate currently performed driver operation. dtr > > > is the function that will be called when either the last refernce to > > > the file goes away or devfs_clear_cdevpriv is called. > > > > > > devfs_get_cdevpriv is the obvious accessor. > > > > > > devfs_clear_cdevpriv allows to clear the private data for the still > > > open file. > > > > > > The synchronization of the cdev data and file private data is left > > > to the driver code, I did not found any generic helper mechanism that > > > could be useful there. > > > > > > Patch: > > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > > > Dumb driver that shows the basic usage of the proposed KPI: > > > http://people.freebsd.org/~kib/misc/fpclone.c > > > > > > Previous version of the patch was tested by Peter Holm. > > > > I like this very much and will use it instead of devfs cloning in ipmi(4) so > > we can use ipmievd when it is committed. IWBN if there was a more automated > > way of handling the unload race, for example if destroy_dev() could somehow > > clear all the per-open fd data. That may not be easily feasible, however. > > (In theory each cdev could have a list of "attached" 'struct file' objects > > that it updates in VOP_CLOSE() and for a destroy dev it detaches all the > > private data after marking the cdev with a bad/null cdevsw, however, that > > would bloat 'struct file' with at least one more pointer (if not two).) > > Probably, I shall clarify that the dtr is called when the last reference > to the struct file going away, unless the priv data is already cleared > by the call to the devfs_clear_cdevpriv. > > The problem with VOP_CLOSE() is that some actions (like forced unmount > or revoke) may cause less calls to the devfs_close then the files > pointing to the cdev. Your proposal basically means that we need, > besides the normal pointers file->vnode->cdev, have the reverse path > cdev->file. I think this is ugly and better be handled by the fdrop(). The disconnect as I see it is that right now destroy_dev() "orphans" devices in that the files still exist but the backing cdev's now have dead operations. However, now you can have a partially orphaned cdev in that not all of the cdev state is torn down in destroy_dev(). In that sense it would be nice to have the behavior described above, and yes you would have to have the cdev's keep track of 'file's as I suggested. Could you handle the revoke(2) and forced umount cases either via VOP_REVOKE() or by adding a VOP_INACTIVE() to devfs? -- John Baldwin