From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 13:39:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEA2916A4CE for ; Mon, 28 Feb 2005 13:39:28 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B64043D1D for ; Mon, 28 Feb 2005 13:39:28 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j1SDd1Z6090227; Mon, 28 Feb 2005 08:39:01 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j1SDd0ti090226; Mon, 28 Feb 2005 08:39:00 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 28 Feb 2005 08:39:00 -0500 From: David Schultz To: Yan Yu Message-ID: <20050228133900.GA90034@VARK.MIT.EDU> Mail-Followup-To: Yan Yu , freebsd-hackers@FreeBSD.ORG References: <20050226072645.76950.qmail@web26802.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-hackers@FreeBSD.ORG Subject: Re: function prototype of fdrop() and fdrop_locked() in kern_descrip.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 13:39:29 -0000 On Sat, Feb 26, 2005, Yan Yu wrote: > HI, all, > I have a Q on the input parameter of fdrop() and fdrop_locked() in > kern/kern_descrip.c. > > i am curious about the design choice of their input parameter. > currently, it is defined as > ---------------------------------------- > A) fdrop( struct file *, struct thread *) > ---------------------------------------- > I added some field in the file descriptor table, and need to do some > bookkeeping whenever a file descriptor is freed. It would be much easier > for me if fdrop() is defined as > --------------------------------- > B) fdrop( int fd, struct thread *) > --------------------------------- > then i could just instrument the fdrop function as opposed to change every > place that calls the fdrop() function. btw, there are more than 100 places > that calls fdrop():( There isn't a one-to-one mapping between file structures and userland file descriptors. After dup(2) is called, for instance, there are two numbers that both map to the same struct file. David Malone gave some other good examples. You will probably want to rethink your design to take this into account. Note that you could instrument the places where syscalls look up userland file descriptors in the fd table if you need to refer to the descriptor number. Just be aware that the number you get won't necessarily correspond to a unique struct file. There are at least two places where this mapping is done: fget_locked() and getvnode(). I think patches to combine them would be gladly accepted. ;-)