From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 15:31:43 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 1572916A4CE; Sun, 27 Mar 2005 15:31:43 +0000 (GMT) Received: from f24.mail.ru (f24.mail.ru [194.67.57.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id A790A43D1D; Sun, 27 Mar 2005 15:31:42 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f24.mail.ru with local id 1DFZjp-000Fvk-00; Sun, 27 Mar 2005 19:31:41 +0400 Received: from [24.185.245.215] by win.mail.ru with HTTP; Sun, 27 Mar 2005 19:31:41 +0400 From: Igor Shmukler To: Robert Watson Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.185.245.215] Date: Sun, 27 Mar 2005 19:31:41 +0400 In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: hackers@freebsd.org Subject: Re[2]: name cache (was Re[4]: vn_fullpath()) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2005 15:31:43 -0000 > On FreeBSD, this occurs because devfs doesn't use the name cache. Two > easy solutions are: > > - Use the name cache in devfs. This would have to be done carefully in > the context of cloning, etc, but should work out. > > - Add a VOP/VFS operation to help figure out a pathname with the help of > the file system, and implement it for devfs. This would avoid having to > deal with cache invalidation issues in devfs. I would prefer whatever would be a lowest impact uniform (for different FSs) solution. I will start looking into this issue. > I'm not familiar with this issue specifically. Normally these descriptors > point to tty's (unnamed due to devfs issues above) and pipes (no name), > which would generally explain the issues. However, the >my.file case is a > bit concerning. Could you confirm that the file descriptor in that case > is definitely pointed at a vnode? I will do this. I would like to point out ( guess I was not clear the first time). That even if std[in/out/err] is VREG, not VCHR after child process inhereted this descriptor vn_fullpath() does not work. I understand that this sounds fishy, because fd simply points to vnode, but that the impression for now. If one closes a "standard" descriptor then opens a file, it does work, but seems not to survive through inheritance. I will follow-up with more information on this. Maybe, files issue for 0..2 is a just a product of imagination :) > Linux does something a little different in how they maintain references to I am aware that Linux dentry/inode/cache are different, but I was asking this for a simple (selfish) reason. If there is a concesus that d_path() like functionality [in a black-box way i.e. let's forget how it is implemented] would be very helpful, then I think if a patch was made it might be committed before 5.5 is out. In that case, I would try to work on this and/or even ask my colleagues to help with coding/testing. If this is viewed as an obscure feature that will not be included anytime soon, I would remove from my agenda for now. I thank you Robert and everyone else who spent time reading this thread and thinking about this whole issue. Thank you, Igor