From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 20:07:29 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2892E1065675 for ; Sun, 7 Dec 2008 20:07:29 +0000 (UTC) (envelope-from peter@wemm.org) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 05B608FC28 for ; Sun, 7 Dec 2008 20:07:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: by rv-out-0506.google.com with SMTP id b25so856131rvf.43 for ; Sun, 07 Dec 2008 12:07:28 -0800 (PST) Received: by 10.142.128.6 with SMTP id a6mr1104447wfd.256.1228680448486; Sun, 07 Dec 2008 12:07:28 -0800 (PST) Received: by 10.142.255.21 with HTTP; Sun, 7 Dec 2008 12:07:28 -0800 (PST) Message-ID: Date: Sun, 7 Dec 2008 12:07:28 -0800 From: "Peter Wemm" To: "Alexander Kabaev" In-Reply-To: <20081207144822.7ff16504@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207114938.44255b35@kan.dnsalias.net> <20081207173755.GN2038@deviant.kiev.zoral.com.ua> <20081207144822.7ff16504@kan.dnsalias.net> Cc: Kostik Belousov , arch@freebsd.org, Joe Marcus Clarke Subject: Re: RFC: New VOP to translate vnode to its component name 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: Sun, 07 Dec 2008 20:07:29 -0000 On Sun, Dec 7, 2008 at 11:48 AM, Alexander Kabaev wrote: > On Sun, 7 Dec 2008 19:37:55 +0200 > Kostik Belousov wrote: > >> On Sun, Dec 07, 2008 at 11:49:38AM -0500, Alexander Kabaev wrote: >> > On Sun, 07 Dec 2008 11:26:08 -0500 >> > Joe Marcus Clarke wrote: >> > >> > > Background: >> > > >> > > Procstat (i.e. kinfo_file) was a great addition which allows >> > > userland processes to get a list of open files for a process >> > > without the need for elevated privileges (e.g. kmem access). >> > > This feature uses the VFS cache to find component names from >> > > vnodes in a process' file descriptor table. Because of its ease >> > > of use, I quickly deployed it into libgtop so that it could >> > > provide an lsof-like feature for FreeBSD. >> > > >> > > Another need arose that seemed perfect for procstat: the ability >> > > to find out what process had the various mouse devices open. >> > > This was needed for X.Org's HAL integration. Unfortunately, due >> > > to the fact that devfs did not make use of the VFS cache, this >> > > was impossible to do without bringing it a lot of kvm code from >> > > fstat, or simply exec'ing fstat periodically. I chose the >> > > latter. The consequence is easier-to-read code, but a >> > > performance hit with default HAL configurations. >> > > >> > > Robert Watson suggested I teach the VFS cache lookup function to >> > > query file systems directly when cache lookups fail. After a few >> > > false starts, and with the help of kib, I think I have a >> > > committable implementation. >> > > >> > > Solution: >> > > >> > > Here is a patch to HEAD, along with a man page, for VOP_CNP. >> > > VOP_CNP translates a vnode to its component name. It is >> > > currently called from vn_fullpath1() to traverse a vnode >> > > hierarchy when cache lookups for those vnodes fail. I have >> > > currently implemented VOP_CNP for devfs and pseudofs. Kostik has >> > > thoroughly reviewed the devfs implementation. I only recently >> > > did the pseudofs implementation at his request. Additionally, the >> > > devfs implementation has gone through a Peter Holm stress test, >> > > and survives (the pseudofs implementation survives WITNESS and >> > > VFS lock debugging). >> > > >> > > I would like to commit this work with a possible MFC to RELENG_7 >> > > to come later. >> > > >> > > http://www.marcuscom.com/downloads/vop_cnp_10.diff >> > > http://www.marcuscom.com/downloads/VOP_CNP.9 >> > > >> > > Joe >> > > >> > In general, the relationship between vnode and componentnames is not >> > 1:1, so I do not see how this VOP can possibly be made a permanent >> > part of our VFS interface, as its definition is bogus by design. >> >> In what sence its definition is bogus ? The vop should try to give a >> component name and a parent directory, if possible. >> > > Which one from possible multiple names should that be and what makes one > name more equal than others? > >> It is perfectly acceptable to have several names, and return whatever >> is considered most suitable. > > > Decides who? This is _generic_ VFS interface we are speaking about, > not procfs or devfs kludge. VOP_CNP is precisely that - a kludge. vn_fullpath() is already this way. It is NOT guaranteed to give you the exact path that was used, but rather *a* working path. It is already using the *first* match it finds in the cache. I see nothing wrong with a generic VOP that asks "tell me A name and parent directory". This is strictly "best effort" only. If you want to determine the actual path, then you're going to need to modify the filedesc and vm_map_* structures to cache the actual pathname used. Of course, that is useless when you start renaming parent directory components, or files get moved, or whatever. Do you have a use in mind that would justify the complexity of changing the VOP_CNP() from returning a single path/parent to instead return a list of path/parent pairs? I don't see this vop needing to spread further than devfs, pseudofs and a 'readdir("..")' default method. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell