From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 16:26:09 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 74E4D1065672 for ; Sun, 7 Dec 2008 16:26:09 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 0983A8FC0C for ; Sun, 7 Dec 2008 16:26:08 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mB7GRnGc022591 for ; Sun, 7 Dec 2008 11:27:49 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: arch@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tv//F06os/NUUK18nANr" Organization: FreeBSD, Inc. Date: Sun, 07 Dec 2008 11:26:08 -0500 Message-Id: <1228667168.69753.16.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Subject: 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 16:26:09 -0000 --=-tv//F06os/NUUK18nANr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-tv//F06os/NUUK18nANr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk7+R8ACgkQb2iPiv4Uz4fGFACgl7YfiCV7rZNjFeNpw+4Dvd2E 6ugAoIyZxSFvm4w62izH1j6w5Izj/t4a =PhJ+ -----END PGP SIGNATURE----- --=-tv//F06os/NUUK18nANr-- From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 17:03:55 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 D1C3A106564A; Sun, 7 Dec 2008 17:03:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 7091C8FC08; Sun, 7 Dec 2008 17:03:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 5B0E51CE48; Sun, 7 Dec 2008 18:03:54 +0100 (CET) Date: Sun, 7 Dec 2008 18:03:54 +0100 From: Ed Schouten To: Joe Marcus Clarke Message-ID: <20081207170354.GI18652@hoeg.nl> References: <1228667168.69753.16.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LYw3s/afESlflPpp" Content-Disposition: inline In-Reply-To: <1228667168.69753.16.camel@shumai.marcuscom.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: arch@FreeBSD.org 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 17:03:55 -0000 --LYw3s/afESlflPpp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Joe, * Joe Marcus Clarke wrote: > Here is a patch to HEAD, along with a man page, for VOP_CNP. Maybe this should be called VOP_COMPONENTNAME? I know, it's not as short as VOP_CNP, but is probably less cryptic to people who are trying to figure out how the VFS works. Yours, --=20 Ed Schouten WWW: http://80386.nl/ --LYw3s/afESlflPpp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkk8AfoACgkQ52SDGA2eCwUgHwCeLdrJ22AAxvMyIxzDz6rXwSsf VIcAn0fcfDBF1rCx9y9qa2+Mrgp05HtY =t+bl -----END PGP SIGNATURE----- --LYw3s/afESlflPpp-- From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 17:16:35 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 30FF71065670 for ; Sun, 7 Dec 2008 17:16:35 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f18.google.com (mail-qy0-f18.google.com [209.85.221.18]) by mx1.freebsd.org (Postfix) with ESMTP id C14AC8FC1A for ; Sun, 7 Dec 2008 17:16:34 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qyk11 with SMTP id 11so942746qyk.19 for ; Sun, 07 Dec 2008 09:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=noGznH+fR7mwKeQHsVdg3SShmxJq4lIDDppoKJE/wjY=; b=DmjvC+gx2Da+zrzponVfWhAeNcSbb9EFpv2ynUdhHbMSEydAATYbCz6H1fjMNTbLcG L5X40LpdJ+Ok2kVQi9SsSQIsPw4ga6POHtvQ8hZ4wD5Bb2d/8u8qXVI22zWrf9qJon0Z aeXGZYee3iVmmI9Sk9zCyGTltD013VGUpcRCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=cT9GTDpKeFVmeKbZwAASAnP9vGG1N5E3TuFcuiXbMxuZFJx2hcbdtcl8CdXKvgqrVT O2vsL3SCLPt9gXSMMLYH42Bn0IslAHXALCtNqJZAWHWHIDE+65EtiS8NYyI3rjNvbX69 bWqi2BAGxeJVfh13MrrAEuW5/bie/teKWhkn0= Received: by 10.214.78.17 with SMTP id a17mr1514259qab.141.1228668589272; Sun, 07 Dec 2008 08:49:49 -0800 (PST) Received: from kan.dnsalias.net (c-24-62-106-68.hsd1.ma.comcast.net [24.62.106.68]) by mx.google.com with ESMTPS id 4sm11742287yxj.7.2008.12.07.08.49.42 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Dec 2008 08:49:48 -0800 (PST) Date: Sun, 7 Dec 2008 11:49:38 -0500 From: Alexander Kabaev To: Joe Marcus Clarke Message-ID: <20081207114938.44255b35@kan.dnsalias.net> In-Reply-To: <1228667168.69753.16.camel@shumai.marcuscom.com> References: <1228667168.69753.16.camel@shumai.marcuscom.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/nSbrU2cOXEbEP1NwvOtBFEZ"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: arch@FreeBSD.org 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 17:16:35 -0000 --Sig_/nSbrU2cOXEbEP1NwvOtBFEZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 07 Dec 2008 11:26:08 -0500 Joe Marcus Clarke wrote: > Background: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Solution: >=20 > 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). >=20 > I would like to commit this work with a possible MFC to RELENG_7 to > come later. >=20 > http://www.marcuscom.com/downloads/vop_cnp_10.diff > http://www.marcuscom.com/downloads/VOP_CNP.9 >=20 > Joe >=20 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. --=20 Alexander Kabaev --Sig_/nSbrU2cOXEbEP1NwvOtBFEZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJO/6iQ6z1jMm+XZYRAtRPAKDVS/53jccwtSK6PYQMUANCEj7GKgCfbeax ui97ex4nvVwFwEYEWUdRlTo= =vDa0 -----END PGP SIGNATURE----- --Sig_/nSbrU2cOXEbEP1NwvOtBFEZ-- From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 17:16:44 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 4C662106564A for ; Sun, 7 Dec 2008 17:16:44 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id ED8EC8FC0C for ; Sun, 7 Dec 2008 17:16:43 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mB7HII5t022980; Sun, 7 Dec 2008 12:18:18 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Ed Schouten In-Reply-To: <20081207170354.GI18652@hoeg.nl> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RuyYTtEspIKH/IiKSty/" Organization: FreeBSD, Inc. Date: Sun, 07 Dec 2008 12:16:37 -0500 Message-Id: <1228670197.69753.24.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: arch@FreeBSD.org 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 17:16:44 -0000 --=-RuyYTtEspIKH/IiKSty/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-12-07 at 18:03 +0100, Ed Schouten wrote: > Hello Joe, >=20 > * Joe Marcus Clarke wrote: > > Here is a patch to HEAD, along with a man page, for VOP_CNP. >=20 > Maybe this should be called VOP_COMPONENTNAME? I know, it's not as short > as VOP_CNP, but is probably less cryptic to people who are trying to > figure out how the VFS works. I'm open to a new name, but VOP_COMPONENTNAME does seem a bit unwieldy. What about VOP_VPTONAME (in the same vein as VOP_VPTOFH)? Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-RuyYTtEspIKH/IiKSty/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk8BPQACgkQb2iPiv4Uz4dcpQCfYPTkbhwr8BBkPVe/PULePXAI T7UAn0Kl3AehlkwEzjmgP2abVCauDtld =P7he -----END PGP SIGNATURE----- --=-RuyYTtEspIKH/IiKSty/-- From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 18:12:34 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 5735F1065678 for ; Sun, 7 Dec 2008 18:12:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id EBA918FC14 for ; Sun, 7 Dec 2008 18:12:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1L9NZv-00043d-B4; Sun, 07 Dec 2008 19:37:59 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mB7HbttC052077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2008 19:37:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mB7HbtFX016924; Sun, 7 Dec 2008 19:37:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mB7Hbth7016922; Sun, 7 Dec 2008 19:37:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 7 Dec 2008 19:37:55 +0200 From: Kostik Belousov To: Alexander Kabaev Message-ID: <20081207173755.GN2038@deviant.kiev.zoral.com.ua> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207114938.44255b35@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HJakWL7yBo69DI1O" Content-Disposition: inline In-Reply-To: <20081207114938.44255b35@kan.dnsalias.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1L9NZv-00043d-B4 e1cb16d4ed73cd1b459317f6fef5f136 X-Terabit: YES Cc: 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 18:12:34 -0000 --HJakWL7yBo69DI1O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > Background: > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > Solution: > >=20 > > 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). > >=20 > > I would like to commit this work with a possible MFC to RELENG_7 to > > come later. > >=20 > > http://www.marcuscom.com/downloads/vop_cnp_10.diff > > http://www.marcuscom.com/downloads/VOP_CNP.9 > >=20 > > Joe > >=20 > 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. It is perfectly acceptable to have several names, and return whatever is considered most suitable. Implementation may choose to always return a third element in some internal list, imagine any weird variant. Devfs implementation falls into this category. Or, it is possible to always return ENOENT, as is done in default implementation. I already discussed a possibility to add helper function that would do the usual readdir("..") to find vnode name for VDIR vnodes, with Peter Wemm. Using it as default implementation of vop_cnp should improve operation of vn_fullpath in general, and esp. on NFS. Personally for me, it would improve the accuracy of still alive patch that adds $ORIGIN support to rtld :). Please, state you objections more explicit. --HJakWL7yBo69DI1O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkk8CfIACgkQC3+MBN1Mb4iZOACePemsWP3N0kWWwW2cb1/DRrwn 3MAAnj7Ga53vCnDgfJWHGuGNbIPrii/G =Nv3E -----END PGP SIGNATURE----- --HJakWL7yBo69DI1O-- From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 19:00:14 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 D5C431065670 for ; Sun, 7 Dec 2008 19:00:14 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBF68FC13 for ; Sun, 7 Dec 2008 19:00:12 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mB7J1kLk023825; Sun, 7 Dec 2008 14:01:46 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Alexander Kabaev In-Reply-To: <20081207114938.44255b35@kan.dnsalias.net> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207114938.44255b35@kan.dnsalias.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5WN0JiyAGvRQA4y7WqGD" Organization: FreeBSD, Inc. Date: Sun, 07 Dec 2008 14:00:05 -0500 Message-Id: <1228676405.69753.30.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: arch@FreeBSD.org 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 19:00:15 -0000 --=-5WN0JiyAGvRQA4y7WqGD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-12-07 at 11:49 -0500, Alexander Kabaev wrote: > On Sun, 07 Dec 2008 11:26:08 -0500 > Joe Marcus Clarke wrote: >=20 > > Background: > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > Solution: > >=20 > > 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). > >=20 > > I would like to commit this work with a possible MFC to RELENG_7 to > > come later. > >=20 > > http://www.marcuscom.com/downloads/vop_cnp_10.diff > > http://www.marcuscom.com/downloads/VOP_CNP.9 > >=20 > > Joe > >=20 > 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. VOP_CNP is not a replacement for VFS cache lookups. It tries to supplement the lookup when the lookup fails to find a hit. VOP_CNP itself may not succeed, or may not be appropriate for every file system (its default implementation simply returns ENOENT). However, it does fit well with devfs and pseudofs, and provides accurate enough results in the general cases. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-5WN0JiyAGvRQA4y7WqGD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk8HTQACgkQb2iPiv4Uz4cuigCfeHQYoiYZc92kGBPWCgQGMwHC YKoAni3MDiB1aAebuIc35RPApXxS1jF8 =hTtR -----END PGP SIGNATURE----- --=-5WN0JiyAGvRQA4y7WqGD-- From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 19:00:35 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 0066A106564A for ; Sun, 7 Dec 2008 19:00:34 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 97BB28FC1B for ; Sun, 7 Dec 2008 19:00:34 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mB7J2FDr023829; Sun, 7 Dec 2008 14:02:15 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Kostik Belousov In-Reply-To: <20081207173755.GN2038@deviant.kiev.zoral.com.ua> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207114938.44255b35@kan.dnsalias.net> <20081207173755.GN2038@deviant.kiev.zoral.com.ua> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GXVcjYwYt/7649pIKibv" Organization: FreeBSD, Inc. Date: Sun, 07 Dec 2008 14:00:34 -0500 Message-Id: <1228676434.69753.33.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: arch@FreeBSD.org 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 19:00:35 -0000 --=-GXVcjYwYt/7649pIKibv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-12-07 at 19:37 +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: > >=20 > > > Background: > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > Robert Watson suggested I teach the VFS cache lookup function to quer= y > > > 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. > > >=20 > > > Solution: > > >=20 > > > 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 fro= m > > > vn_fullpath1() to traverse a vnode hierarchy when cache lookups for > > > those vnodes fail. I have currently implemented VOP_CNP for devfs an= d > > > 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). > > >=20 > > > I would like to commit this work with a possible MFC to RELENG_7 to > > > come later. > > >=20 > > > http://www.marcuscom.com/downloads/vop_cnp_10.diff > > > http://www.marcuscom.com/downloads/VOP_CNP.9 > > >=20 > > > Joe > > >=20 > > 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. >=20 > In what sence its definition is bogus ? The vop should try to give a > component name and a parent directory, if possible. >=20 > It is perfectly acceptable to have several names, and return whatever > is considered most suitable. Implementation may choose to always return > a third element in some internal list, imagine any weird variant. Devfs > implementation falls into this category. As does the pseudofs implementation which handles the case of a directory on a procfs file system specially. Even though the directory has a pn_name of "pid," the VOP_CNP returns the PID as the name instead. > Or, it is possible to always return ENOENT, as is done in default > implementation. >=20 > I already discussed a possibility to add helper function that would > do the usual readdir("..") to find vnode name for VDIR vnodes, with > Peter Wemm. Using it as default implementation of vop_cnp should improve > operation of vn_fullpath in general, and esp. on NFS. Yes, Peter briefly mentioned this to me as well. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-GXVcjYwYt/7649pIKibv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk8HVEACgkQb2iPiv4Uz4eZZQCgjZ+DK6vEW9ae21uYXPggjbBu jswAoJQs2ZvUvKa14Bq1WxWOf5yOA29j =IPV+ -----END PGP SIGNATURE----- --=-GXVcjYwYt/7649pIKibv-- From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 19:39:55 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 E323A1065679 for ; Sun, 7 Dec 2008 19:39:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CAE048FC36 for ; Sun, 7 Dec 2008 19:39:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id DCDA41A3C3A; Sun, 7 Dec 2008 11:39:53 -0800 (PST) Date: Sun, 7 Dec 2008 11:39:53 -0800 From: Alfred Perlstein To: Joe Marcus Clarke Message-ID: <20081207193953.GJ27096@elvis.mu.org> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1228670197.69753.24.camel@shumai.marcuscom.com> User-Agent: Mutt/1.4.2.3i Cc: Ed Schouten , arch@FreeBSD.org 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 19:39:56 -0000 * Joe Marcus Clarke [081207 09:17] wrote: > On Sun, 2008-12-07 at 18:03 +0100, Ed Schouten wrote: > > Hello Joe, > > > > * Joe Marcus Clarke wrote: > > > Here is a patch to HEAD, along with a man page, for VOP_CNP. > > > > Maybe this should be called VOP_COMPONENTNAME? I know, it's not as short > > as VOP_CNP, but is probably less cryptic to people who are trying to > > figure out how the VFS works. > > I'm open to a new name, but VOP_COMPONENTNAME does seem a bit unwieldy. > What about VOP_VPTONAME (in the same vein as VOP_VPTOFH)? either VOP_VPTONAME or VOP_VPTOCNP (this is cool) -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 19:43:02 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 A69071065675 for ; Sun, 7 Dec 2008 19:43:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id 856498FC28 for ; Sun, 7 Dec 2008 19:43:02 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wf-out-1314.google.com with SMTP id 24so933386wfg.7 for ; Sun, 07 Dec 2008 11:43:02 -0800 (PST) Received: by 10.143.155.7 with SMTP id h7mr1098425wfo.153.1228678982075; Sun, 07 Dec 2008 11:43:02 -0800 (PST) Received: by 10.142.255.21 with HTTP; Sun, 7 Dec 2008 11:43:02 -0800 (PST) Message-ID: Date: Sun, 7 Dec 2008 11:43:02 -0800 From: "Peter Wemm" To: "Joe Marcus Clarke" In-Reply-To: <1228670197.69753.24.camel@shumai.marcuscom.com> 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> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> Cc: Ed Schouten , arch@freebsd.org 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 19:43:02 -0000 On Sun, Dec 7, 2008 at 9:16 AM, Joe Marcus Clarke wrote: > On Sun, 2008-12-07 at 18:03 +0100, Ed Schouten wrote: >> Hello Joe, >> >> * Joe Marcus Clarke wrote: >> > Here is a patch to HEAD, along with a man page, for VOP_CNP. >> >> Maybe this should be called VOP_COMPONENTNAME? I know, it's not as short >> as VOP_CNP, but is probably less cryptic to people who are trying to >> figure out how the VFS works. > > I'm open to a new name, but VOP_COMPONENTNAME does seem a bit unwieldy. > What about VOP_VPTONAME (in the same vein as VOP_VPTOFH)? > > Joe Well, you already know I love the idea. Valgrind "knows" that you can obtain the pathname from a fd or mmap address reliably at any time because of procfs on linux, so its code is structured with that assumption. Using procfs (on 4.x and 6.x) or the kinfo stuff on 7.x+ sort of works, but it quickly becomes unusable if any paths involve NFS. nfs times out its cached items very quickly. Anyway, I see this as a good first step. I very much want to see a real vop_default implementation that does the readdir("..") method to fill in the gaps. It isn't particularly important to me if vn_fullpath() recovers the original pathname or not, so long as it can find *a* valid pathname that will work. As for names.. VOP_CNP doesn't tell me what it does at a glance. Ideas: VOP_VPTOCNP (vnode to component name, or VOP_VNTOCNP) VOP_RLOOKUP (reverse lookup) We have precedent for the first form. VOP_FHTOVP(). I don't think VOP_VPTOCNP() is too unwieldy and I think it would be a little more intuitive to a casual observer. I don't want to get trapped in a bikeshed sized To:/CC: list over it though. I'd rather see it committed to head and get some progress. BTW: at work we do extensive open-by-filehandle stuff on NFS. For the vast majority of vnodes on those machines, there never was a name cache entry. It would be priceless if the vop_default readdir(..) method could discover those names in procstat etc. -- 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 From owner-freebsd-arch@FreeBSD.ORG Sun Dec 7 19:48:32 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 2FA2B106564A for ; Sun, 7 Dec 2008 19:48:32 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id CF4398FC0C for ; Sun, 7 Dec 2008 19:48:31 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so201196qwb.7 for ; Sun, 07 Dec 2008 11:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=1+YhY0bWSqjKk3ddgS1VSBoLMyBuCXu55zvn39qL8S8=; b=igQeA6JdGvZu1hOVs1zgjYqFQIvq1HJbftuG1f3mwx2d7UvkPsuIAyN6i0jIf44S+A xABAo3Wi5Kv7cdzGmSC3dh+W2vZeBJNiHrWoP4ZhbTAxpwbP+Kr5fDqX0NAAXRjJjayM p9r8SVJPKMK0tVt3bwF4lH205cXF5rvJwHPDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=WNHq1X3XOATkCYhb6U3Tn0Urj3jYREGl/jaG33mtrlIcEeYHHz8PydJdcQEWfXDY49 Z9sF+AGq7TyvEmXtsBvC5VZS0ZoDui6Lm0R+E00Tu53WSE4tdY6qVIIdTiwnFIvGohky 2fSaUbNMaTsblyMwsq6JKfRYN89LicafvIOhw= Received: by 10.215.100.13 with SMTP id c13mr1604674qam.353.1228679307879; Sun, 07 Dec 2008 11:48:27 -0800 (PST) Received: from kan.dnsalias.net (c-24-62-106-68.hsd1.ma.comcast.net [24.62.106.68]) by mx.google.com with ESMTPS id 9sm13318442yxs.5.2008.12.07.11.48.26 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Dec 2008 11:48:27 -0800 (PST) Date: Sun, 7 Dec 2008 14:48:22 -0500 From: Alexander Kabaev To: Kostik Belousov Message-ID: <20081207144822.7ff16504@kan.dnsalias.net> In-Reply-To: <20081207173755.GN2038@deviant.kiev.zoral.com.ua> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207114938.44255b35@kan.dnsalias.net> <20081207173755.GN2038@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/ay58P7kCqsgiO_6Z18607Qb"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: 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 19:48:32 -0000 --Sig_/ay58P7kCqsgiO_6Z18607Qb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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: > >=20 > > > Background: > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > Solution: > > >=20 > > > 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). > > >=20 > > > I would like to commit this work with a possible MFC to RELENG_7 > > > to come later. > > >=20 > > > http://www.marcuscom.com/downloads/vop_cnp_10.diff > > > http://www.marcuscom.com/downloads/VOP_CNP.9 > > >=20 > > > Joe > > >=20 > > 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. >=20 > 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. > Implementation may choose to always > return a third element in some internal list, imagine any weird > variant. Devfs implementation falls into this category. > Or, it is possible to always return ENOENT, as is done in default > implementation. >=20 > I already discussed a possibility to add helper function that would > do the usual readdir("..") to find vnode name for VDIR vnodes, with > Peter Wemm. Using it as default implementation of vop_cnp should > improve operation of vn_fullpath in general, and esp. on NFS. Then it does belong in vn_fullpatch and not as VNODE operation. =20 > Personally for me, it would improve the accuracy of still alive patch > that adds $ORIGIN support to rtld :). >=20 > Please, state you objections more explicit. I believe I did. --=20 Alexander Kabaev --Sig_/ay58P7kCqsgiO_6Z18607Qb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJPCiGQ6z1jMm+XZYRAsrAAKCPTJL38Q1OOxpCRcBtqYIFY4WkigCgvZ33 YtUKVPz7EcxjX2cfO+e11eI= =3oqI -----END PGP SIGNATURE----- --Sig_/ay58P7kCqsgiO_6Z18607Qb-- 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 From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 10:20:25 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 AEB0A1065673 for ; Mon, 8 Dec 2008 10:20:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6D52A8FC1A for ; Mon, 8 Dec 2008 10:20:25 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 7B75A6D44E; Mon, 8 Dec 2008 10:20:24 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 57D01844BD; Mon, 8 Dec 2008 11:20:24 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Joe Marcus Clarke References: <1228667168.69753.16.camel@shumai.marcuscom.com> Date: Mon, 08 Dec 2008 11:20:24 +0100 In-Reply-To: <1228667168.69753.16.camel@shumai.marcuscom.com> (Joe Marcus Clarke's message of "Sun, 07 Dec 2008 11:26:08 -0500") Message-ID: <86tz9fynmf.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org 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: Mon, 08 Dec 2008 10:20:25 -0000 Joe Marcus Clarke writes: > 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. I would prefer pidbuf[PFS_NAMLEN] to pidbuf[11], and you can avoid two strlen()s by storing the return value from snprintf(). Also, defining pidbuf at the start of the block instead of the start of the function is a style(9) violation. Other than that, the pseudofs part of the patch has my approval. BTW, snprintf(buf, buflen, "%d", i) is so common in the kernel that we should consider adding some sort of itoa(9) to avoid the overhead of snprintf(9). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 11:06:52 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 DE0C2106564A for ; Mon, 8 Dec 2008 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B24648FC1B for ; Mon, 8 Dec 2008 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB8B6qSk014196 for ; Mon, 8 Dec 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB8B6q6q014192 for freebsd-arch@FreeBSD.org; Mon, 8 Dec 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Dec 2008 11:06:52 GMT Message-Id: <200812081106.mB8B6q6q014192@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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, 08 Dec 2008 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 17:28:04 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 8C2FD106564A for ; Mon, 8 Dec 2008 17:28:04 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 190F78FC22 for ; Mon, 8 Dec 2008 17:28:03 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mB8HTjdE034314; Mon, 8 Dec 2008 12:29:46 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86tz9fynmf.fsf@ds4.des.no> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <86tz9fynmf.fsf@ds4.des.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-n0RvummTzj+AenzdrfD+" Organization: FreeBSD, Inc. Date: Mon, 08 Dec 2008 12:28:03 -0500 Message-Id: <1228757283.69132.14.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: arch@FreeBSD.org 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: Mon, 08 Dec 2008 17:28:04 -0000 --=-n0RvummTzj+AenzdrfD+ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 2008-12-08 at 11:20 +0100, Dag-Erling Sm=F8rgrav wrote: > Joe Marcus Clarke writes: > > 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. >=20 > I would prefer pidbuf[PFS_NAMLEN] to pidbuf[11], and you can avoid two > strlen()s by storing the return value from snprintf(). Also, defining > pidbuf at the start of the block instead of the start of the function is > a style(9) violation. Other than that, the pseudofs part of the patch > has my approval. Thanks for the feedback. This was a section of the pfs code I especially wanted some comments on. I'll take care of your suggestions. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-n0RvummTzj+AenzdrfD+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk9WSAACgkQb2iPiv4Uz4dFbgCeMyEWYjM2gPN3FtMNaSWI8VuR Uo4AniLI5atkL0eWolKlxsnx40/S58G+ =4Ndi -----END PGP SIGNATURE----- --=-n0RvummTzj+AenzdrfD+-- From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 17:53:28 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 77D941065673; Mon, 8 Dec 2008 17:53:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 15C168FC08; Mon, 8 Dec 2008 17:53:27 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 2B30E1CE1F; Mon, 8 Dec 2008 18:53:27 +0100 (CET) Date: Mon, 8 Dec 2008 18:53:27 +0100 From: Ed Schouten To: Joe Marcus Clarke Message-ID: <20081208175327.GA7013@hoeg.nl> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <1228670197.69753.24.camel@shumai.marcuscom.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: arch@FreeBSD.org 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: Mon, 08 Dec 2008 17:53:28 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Joe Marcus Clarke wrote: > On Sun, 2008-12-07 at 18:03 +0100, Ed Schouten wrote: > > Maybe this should be called VOP_COMPONENTNAME? I know, it's not as short > > as VOP_CNP, but is probably less cryptic to people who are trying to > > figure out how the VFS works. >=20 > I'm open to a new name, but VOP_COMPONENTNAME does seem a bit unwieldy. > What about VOP_VPTONAME (in the same vein as VOP_VPTOFH)? Sounds good. :-) --=20 Ed Schouten WWW: http://80386.nl/ --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkk9XxcACgkQ52SDGA2eCwUmDQCggGO2NWDXc0rIk7zRMIFgfvKs ROUAn2GQmuaBugWu6GFi65BRH+SXzgzO =L9yl -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 18:08:14 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 3A15B1065679; Mon, 8 Dec 2008 18:08:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 135338FC1E; Mon, 8 Dec 2008 18:08:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id AA9B846B9B; Mon, 8 Dec 2008 13:08:13 -0500 (EST) Date: Mon, 8 Dec 2008 18:08:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Wemm In-Reply-To: Message-ID: References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , Joe Marcus Clarke , arch@freebsd.org 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: Mon, 08 Dec 2008 18:08:14 -0000 On Sun, 7 Dec 2008, Peter Wemm wrote: > Well, you already know I love the idea. Valgrind "knows" that you can > obtain the pathname from a fd or mmap address reliably at any time because > of procfs on linux, so its code is structured with that assumption. Just to give a general vote of "we need to do something here, whether the details are exactly these or not" -- having better object->path resolution is quite important for audit, as well as if we want to adopt a file system notification services along the lines of Apple's fsevents (which is path-centric and operates from close() events rather than open() events). I don't think we should run in the Linux 'dentry' direction, but having a more robust translation service would be quite valuable. One comment: I think we should continue to have a KPI which does a sleep-free translation to call, but with weaker semantics than one that is sleepable and can query for more robust reverse lookup. Robert N M Watson Computer Laboratory University of Cambridge > > Using procfs (on 4.x and 6.x) or the kinfo stuff on 7.x+ sort of > works, but it quickly becomes unusable if any paths involve NFS. nfs > times out its cached items very quickly. > > Anyway, I see this as a good first step. I very much want to see a > real vop_default implementation that does the readdir("..") method to > fill in the gaps. It isn't particularly important to me if > vn_fullpath() recovers the original pathname or not, so long as it can > find *a* valid pathname that will work. > > As for names.. VOP_CNP doesn't tell me what it does at a glance. Ideas: > VOP_VPTOCNP (vnode to component name, or VOP_VNTOCNP) > VOP_RLOOKUP (reverse lookup) > > We have precedent for the first form. VOP_FHTOVP(). > > I don't think VOP_VPTOCNP() is too unwieldy and I think it would be a > little more intuitive to a casual observer. I don't want to get > trapped in a bikeshed sized To:/CC: list over it though. I'd rather > see it committed to head and get some progress. > > BTW: at work we do extensive open-by-filehandle stuff on NFS. For the > vast majority of vnodes on those machines, there never was a name > cache entry. It would be priceless if the vop_default readdir(..) > method could discover those names in procstat etc. > > -- > 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 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 18:08:16 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 5F7C7106564A for ; Mon, 8 Dec 2008 18:08:16 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id DD7358FC1F for ; Mon, 8 Dec 2008 18:08:15 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mB8I9qTf034597; Mon, 8 Dec 2008 13:09:52 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86tz9fynmf.fsf@ds4.des.no> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <86tz9fynmf.fsf@ds4.des.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-noSkFy4fnwIg/pQkUg5F" Organization: FreeBSD, Inc. Date: Mon, 08 Dec 2008 13:08:10 -0500 Message-Id: <1228759690.69132.28.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: arch@FreeBSD.org 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: Mon, 08 Dec 2008 18:08:16 -0000 --=-noSkFy4fnwIg/pQkUg5F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 2008-12-08 at 11:20 +0100, Dag-Erling Sm=F8rgrav wrote: > Joe Marcus Clarke writes: > > 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. >=20 > I would prefer pidbuf[PFS_NAMLEN] to pidbuf[11], and you can avoid two > strlen()s by storing the return value from snprintf(). Also, defining > pidbuf at the start of the block instead of the start of the function is > a style(9) violation. Other than that, the pseudofs part of the patch > has my approval. http://www.marcuscom.com/downloads/vop_vptocnp_5.diff Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-noSkFy4fnwIg/pQkUg5F Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk9YogACgkQb2iPiv4Uz4dUXgCgojsrLAC9O5GyFKZOtOt6eGtR jd0An39tc2SpS5Ffnrjfu+2JcWuSCfcp =EMGp -----END PGP SIGNATURE----- --=-noSkFy4fnwIg/pQkUg5F-- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 01:06:51 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 9A54C106564A; Tue, 9 Dec 2008 01:06:51 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 5896D8FC16; Tue, 9 Dec 2008 01:06:51 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mB918Sxi037921; Mon, 8 Dec 2008 20:08:28 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Robert Watson In-Reply-To: References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AiGQsYX7/l7OWYkYDg0Q" Organization: FreeBSD, Inc. Date: Mon, 08 Dec 2008 20:06:45 -0500 Message-Id: <1228784805.69132.66.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, NO_RELAYS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Ed Schouten , arch@FreeBSD.org 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: Tue, 09 Dec 2008 01:06:51 -0000 --=-AiGQsYX7/l7OWYkYDg0Q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-12-08 at 18:08 +0000, Robert Watson wrote: > On Sun, 7 Dec 2008, Peter Wemm wrote: >=20 > > Well, you already know I love the idea. Valgrind "knows" that you can=20 > > obtain the pathname from a fd or mmap address reliably at any time beca= use=20 > > of procfs on linux, so its code is structured with that assumption. >=20 > Just to give a general vote of "we need to do something here, whether the= =20 > details are exactly these or not" -- having better object->path resolutio= n is=20 > quite important for audit, as well as if we want to adopt a file system=20 > notification services along the lines of Apple's fsevents (which is=20 > path-centric and operates from close() events rather than open() events).= I=20 > don't think we should run in the Linux 'dentry' direction, but having a m= ore=20 > robust translation service would be quite valuable. One comment: I think= we=20 > should continue to have a KPI which does a sleep-free translation to call= , but=20 > with weaker semantics than one that is sleepable and can query for more r= obust=20 > reverse lookup. Okay, what about a name? vn_fullpath_cache vn_fullpath_quick vn_fullpath_fast vn_fullpath_nosleep ... Joe >=20 > Robert N M Watson > Computer Laboratory > University of Cambridge >=20 > > > > Using procfs (on 4.x and 6.x) or the kinfo stuff on 7.x+ sort of > > works, but it quickly becomes unusable if any paths involve NFS. nfs > > times out its cached items very quickly. > > > > Anyway, I see this as a good first step. I very much want to see a > > real vop_default implementation that does the readdir("..") method to > > fill in the gaps. It isn't particularly important to me if > > vn_fullpath() recovers the original pathname or not, so long as it can > > find *a* valid pathname that will work. > > > > As for names.. VOP_CNP doesn't tell me what it does at a glance. Ideas= : > > VOP_VPTOCNP (vnode to component name, or VOP_VNTOCNP) > > VOP_RLOOKUP (reverse lookup) > > > > We have precedent for the first form. VOP_FHTOVP(). > > > > I don't think VOP_VPTOCNP() is too unwieldy and I think it would be a > > little more intuitive to a casual observer. I don't want to get > > trapped in a bikeshed sized To:/CC: list over it though. I'd rather > > see it committed to head and get some progress. > > > > BTW: at work we do extensive open-by-filehandle stuff on NFS. For the > > vast majority of vnodes on those machines, there never was a name > > cache entry. It would be priceless if the vop_default readdir(..) > > method could discover those names in procstat etc. > > > > --=20 > > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV > > "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 > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > >=20 --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-AiGQsYX7/l7OWYkYDg0Q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk9xKQACgkQb2iPiv4Uz4cc6ACdEyt3GfrgbK1WHn9K7XS9WTJS PfwAn2HMmgU9j03VMCQTpq/J1Po7gw/+ =yXBP -----END PGP SIGNATURE----- --=-AiGQsYX7/l7OWYkYDg0Q-- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 11:22:30 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 B74E61065676; Tue, 9 Dec 2008 11:22:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7680E8FC08; Tue, 9 Dec 2008 11:22:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 11D5046B38; Tue, 9 Dec 2008 06:22:30 -0500 (EST) Date: Tue, 9 Dec 2008 11:22:29 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Joe Marcus Clarke In-Reply-To: <1228784805.69132.66.camel@shumai.marcuscom.com> Message-ID: References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> <1228784805.69132.66.camel@shumai.marcuscom.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Ed Schouten , arch@FreeBSD.org 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: Tue, 09 Dec 2008 11:22:30 -0000 On Mon, 8 Dec 2008, Joe Marcus Clarke wrote: >> Just to give a general vote of "we need to do something here, whether the >> details are exactly these or not" -- having better object->path resolution >> is quite important for audit, as well as if we want to adopt a file system >> notification services along the lines of Apple's fsevents (which is >> path-centric and operates from close() events rather than open() events). >> I don't think we should run in the Linux 'dentry' direction, but having a >> more robust translation service would be quite valuable. One comment: I >> think we should continue to have a KPI which does a sleep-free translation >> to call, but with weaker semantics than one that is sleepable and can query >> for more robust reverse lookup. > > Okay, what about a name? Oh, I do love a good bikeshed. I'm actually fine with any of these, but vn_fullpath_cache() sounds good to me. One of the cases I have in mind is path-based MAC policies, which will convert from a vnode to a path while holding the vnode lock -- if something is going to run around locking vnodes and doing VOP_READDIR's, that is not the time to do it. Robert N M Watson Computer Laboratory University of Cambridge > > vn_fullpath_cache > vn_fullpath_quick > vn_fullpath_fast > vn_fullpath_nosleep > ... > > Joe > >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> >>> Using procfs (on 4.x and 6.x) or the kinfo stuff on 7.x+ sort of >>> works, but it quickly becomes unusable if any paths involve NFS. nfs >>> times out its cached items very quickly. >>> >>> Anyway, I see this as a good first step. I very much want to see a >>> real vop_default implementation that does the readdir("..") method to >>> fill in the gaps. It isn't particularly important to me if >>> vn_fullpath() recovers the original pathname or not, so long as it can >>> find *a* valid pathname that will work. >>> >>> As for names.. VOP_CNP doesn't tell me what it does at a glance. Ideas: >>> VOP_VPTOCNP (vnode to component name, or VOP_VNTOCNP) >>> VOP_RLOOKUP (reverse lookup) >>> >>> We have precedent for the first form. VOP_FHTOVP(). >>> >>> I don't think VOP_VPTOCNP() is too unwieldy and I think it would be a >>> little more intuitive to a casual observer. I don't want to get >>> trapped in a bikeshed sized To:/CC: list over it though. I'd rather >>> see it committed to head and get some progress. >>> >>> BTW: at work we do extensive open-by-filehandle stuff on NFS. For the >>> vast majority of vnodes on those machines, there never was a name >>> cache entry. It would be priceless if the vop_default readdir(..) >>> method could discover those names in procstat etc. >>> >>> -- >>> 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 >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> >> > -- > Joe Marcus Clarke > FreeBSD GNOME Team :: gnome@FreeBSD.org > FreeNode / #freebsd-gnome > http://www.FreeBSD.org/gnome > From owner-freebsd-arch@FreeBSD.ORG Tue Dec 9 17:31:27 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 3BD6A106564A; Tue, 9 Dec 2008 17:31:27 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id F1C158FC12; Tue, 9 Dec 2008 17:31:26 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id E62B06D43F; Tue, 9 Dec 2008 17:31:25 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id CA055844BD; Tue, 9 Dec 2008 18:31:25 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Joe Marcus Clarke References: <1228667168.69753.16.camel@shumai.marcuscom.com> <86tz9fynmf.fsf@ds4.des.no> <1228759690.69132.28.camel@shumai.marcuscom.com> Date: Tue, 09 Dec 2008 18:31:25 +0100 In-Reply-To: <1228759690.69132.28.camel@shumai.marcuscom.com> (Joe Marcus Clarke's message of "Mon, 08 Dec 2008 13:08:10 -0500") Message-ID: <861vwhz24y.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org 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: Tue, 09 Dec 2008 17:31:27 -0000 Joe Marcus Clarke writes: > http://www.marcuscom.com/downloads/vop_vptocnp_5.diff Looks good as far as pseudofs is concerned. Thank you. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Dec 10 02:24:34 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 683381065678 for ; Wed, 10 Dec 2008 02:24:34 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by mx1.freebsd.org (Postfix) with ESMTP id 2039D8FC08 for ; Wed, 10 Dec 2008 02:24:33 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rn-out-0910.google.com with SMTP id j71so335451rne.12 for ; Tue, 09 Dec 2008 18:24:33 -0800 (PST) Received: by 10.150.145.20 with SMTP id s20mr505217ybd.121.1228875872426; Tue, 09 Dec 2008 18:24:32 -0800 (PST) Received: from ?10.0.1.199? (udp005586uds.hawaiiantel.net [72.234.105.237]) by mx.google.com with ESMTPS id k35sm2345243rnd.3.2008.12.09.18.24.30 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Dec 2008 18:24:31 -0800 (PST) Date: Tue, 9 Dec 2008 16:22:44 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: arch@freebsd.org Message-ID: <20081209155714.K960@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: UMA & mbuf cache utilization. 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: Wed, 10 Dec 2008 02:24:34 -0000 Hello, Nokia has graciously allowed me to release a patch which I developed to improve general mbuf and cluster cache behavior. This is based on others observations that due to simple alignment at 2k and 256k we achieve a poor cache distribution for the header area of packets and the most heavily used mbuf header fields. In addition, modern machines stripe memory access across several memories and even memory controllers. Accessing heavily aligned locations such as these can also create load imbalances among memories. To solve this problem I have added two new features to UMA. The first is the zone flag UMA_ZONE_CACHESPREAD. This flag modifies the meaning of the alignment field such that start addresses are staggered by at least align + 1 bytes. In the case of clusters and mbufs this means adding uma_cache_align + 1 bytes to the amount of storage allocated. This creates a certain constant amount of waste, 3% and 12% respectively. It also means we must use contiguous physical and virtual memory consisting of several pages to efficiently use the memory and land on as many cache lines as possible. Because contiguous physical memory is not always available, the allocator had to have a fallback mechanism. We don't simply want to have all mbuf allocations check two zones as once we deplete available contiguous memory the check on the first zone will always fail using the most expensive code path. To resolve this issue, I added the ability for secondary zones to stack on top of multiple primary zones. Secondary zones are zones which get their storage from another zone but handle their own caching, ctors, dtors, etc. By adding this feature a secondary zone can be created that can allocate either from the contiguous memory pool or the non-contiguous single-page pool depending on availability. It is also much faster to fail between them deep in the allocator because it is only required when we exhaust the already available mbuf memory. For mbufs and clusters there are now three zones each. A contigmalloc backed zone, a single-page allocator zone, and a secondary zone with the original zome_mbuf or zone_clust name. The packet zone also takes from both available mbuf zones. The individual backend zones are not exposed outside of kern_mbuf.c. Currently, each backend zone can have its own limit. The secondary zone only blocks when both are full. Statistic wise the limit should be reported as the sum of the backend limits, however, that isn't presently done. The secondary zone can not have its own limit independent of the backends at this time. I'm not sure if that's valuable or not. I have test results from nokia which show a dramatic improvement in several workloads but which I am probably not at liberty to discuss. I'm in the process of convincing Kip to help me get some benchmark data on our stack. Also as part of the patch I renamed a few functions since many were non-obvious and grew new keg abstractions to tidy things up a bit. I suspect those of you with UMA experience (robert, bosko) will find the renaming a welcome improvement. The patch is available at: http://people.freebsd.org/~jeff/mbuf_contig.diff I would love to hear any feedback you may have. I have been developing this and testing various version off and on for months, however, this is a fresh port to current and it is a little green so should be considered experimental. In particular, I'm most nervous about how the vm will respond to new pressure on contig physical pages. I'm also interested in hearing from embedded/limited memory people about how we might want to limit or tune this. Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Wed Dec 10 07:32:25 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 11AB71065670; Wed, 10 Dec 2008 07:32:25 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id A01E28FC13; Wed, 10 Dec 2008 07:32:24 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mBA7Y9aY054341; Wed, 10 Dec 2008 02:34:09 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Robert Watson In-Reply-To: References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> <1228784805.69132.66.camel@shumai.marcuscom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4kroQkURKgDuEQXfhAx6" Organization: FreeBSD, Inc. Date: Wed, 10 Dec 2008 02:32:24 -0500 Message-Id: <1228894344.35477.40.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, NO_RELAYS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Ed Schouten , arch@FreeBSD.org 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: Wed, 10 Dec 2008 07:32:25 -0000 --=-4kroQkURKgDuEQXfhAx6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-12-09 at 11:22 +0000, Robert Watson wrote: > On Mon, 8 Dec 2008, Joe Marcus Clarke wrote: >=20 > >> Just to give a general vote of "we need to do something here, whether = the=20 > >> details are exactly these or not" -- having better object->path resolu= tion=20 > >> is quite important for audit, as well as if we want to adopt a file sy= stem=20 > >> notification services along the lines of Apple's fsevents (which is=20 > >> path-centric and operates from close() events rather than open() event= s).=20 > >> I don't think we should run in the Linux 'dentry' direction, but havin= g a=20 > >> more robust translation service would be quite valuable. One comment:= I=20 > >> think we should continue to have a KPI which does a sleep-free transla= tion=20 > >> to call, but with weaker semantics than one that is sleepable and can = query=20 > >> for more robust reverse lookup. > > > > Okay, what about a name? >=20 > Oh, I do love a good bikeshed. I'm actually fine with any of these, but=20 > vn_fullpath_cache() sounds good to me. One of the cases I have in mind i= s=20 > path-based MAC policies, which will convert from a vnode to a path while=20 > holding the vnode lock -- if something is going to run around locking vno= des=20 > and doing VOP_READDIR's, that is not the time to do it. I've duplicated vn_fullpath, vn_fullpath_global, and textvp_fullpath in this latest version. The new (well, old) functions are named *_cache. I even updated the vn_fullpath.9 man page. http://www.marcuscom.com/downloads/vop_vptocnp_7.diff Joe >=20 > Robert N M Watson > Computer Laboratory > University of Cambridge >=20 > > > > vn_fullpath_cache > > vn_fullpath_quick > > vn_fullpath_fast > > vn_fullpath_nosleep > > ... > > > > Joe > > > >> > >> Robert N M Watson > >> Computer Laboratory > >> University of Cambridge > >> > >>> > >>> Using procfs (on 4.x and 6.x) or the kinfo stuff on 7.x+ sort of > >>> works, but it quickly becomes unusable if any paths involve NFS. nfs > >>> times out its cached items very quickly. > >>> > >>> Anyway, I see this as a good first step. I very much want to see a > >>> real vop_default implementation that does the readdir("..") method to > >>> fill in the gaps. It isn't particularly important to me if > >>> vn_fullpath() recovers the original pathname or not, so long as it ca= n > >>> find *a* valid pathname that will work. > >>> > >>> As for names.. VOP_CNP doesn't tell me what it does at a glance. Ide= as: > >>> VOP_VPTOCNP (vnode to component name, or VOP_VNTOCNP) > >>> VOP_RLOOKUP (reverse lookup) > >>> > >>> We have precedent for the first form. VOP_FHTOVP(). > >>> > >>> I don't think VOP_VPTOCNP() is too unwieldy and I think it would be a > >>> little more intuitive to a casual observer. I don't want to get > >>> trapped in a bikeshed sized To:/CC: list over it though. I'd rather > >>> see it committed to head and get some progress. > >>> > >>> BTW: at work we do extensive open-by-filehandle stuff on NFS. For th= e > >>> vast majority of vnodes on those machines, there never was a name > >>> cache entry. It would be priceless if the vop_default readdir(..) > >>> method could discover those names in procstat etc. > >>> > >>> -- > >>> 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 > >>> _______________________________________________ > >>> freebsd-arch@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch > >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.or= g" > >>> > >> > > --=20 > > Joe Marcus Clarke > > FreeBSD GNOME Team :: gnome@FreeBSD.org > > FreeNode / #freebsd-gnome > > http://www.FreeBSD.org/gnome > > >=20 --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-4kroQkURKgDuEQXfhAx6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkk/cIcACgkQb2iPiv4Uz4drigCcDwegRzzJi6D2R99oD+1WQG0+ XrwAn2uJzcpJVrqOHuCWY2fV5xXqfa6D =tXYQ -----END PGP SIGNATURE----- --=-4kroQkURKgDuEQXfhAx6-- From owner-freebsd-arch@FreeBSD.ORG Wed Dec 10 16:23:19 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 1662B106567B; Wed, 10 Dec 2008 16:23:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id AA1EC8FC13; Wed, 10 Dec 2008 16:23:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LARqG-000PXl-SE; Wed, 10 Dec 2008 18:23:17 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBAGNDJf052312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 18:23:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBAGNDBo018561; Wed, 10 Dec 2008 18:23:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBAGND3n018559; Wed, 10 Dec 2008 18:23:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Dec 2008 18:23:12 +0200 From: Kostik Belousov To: Joe Marcus Clarke Message-ID: <20081210162312.GO2038@deviant.kiev.zoral.com.ua> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> <1228784805.69132.66.camel@shumai.marcuscom.com> <1228894344.35477.40.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3h+hNn3PVp185ISI" Content-Disposition: inline In-Reply-To: <1228894344.35477.40.camel@shumai.marcuscom.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LARqG-000PXl-SE 851d7fa9d366cdfbcc75c4b78d3352a4 X-Terabit: YES Cc: Ed Schouten , Robert Watson , arch@freebsd.org 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: Wed, 10 Dec 2008 16:23:19 -0000 --3h+hNn3PVp185ISI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2008 at 02:32:24AM -0500, Joe Marcus Clarke wrote: > On Tue, 2008-12-09 at 11:22 +0000, Robert Watson wrote: > > On Mon, 8 Dec 2008, Joe Marcus Clarke wrote: > >=20 > > >> Just to give a general vote of "we need to do something here, whethe= r the=20 > > >> details are exactly these or not" -- having better object->path reso= lution=20 > > >> is quite important for audit, as well as if we want to adopt a file = system=20 > > >> notification services along the lines of Apple's fsevents (which is= =20 > > >> path-centric and operates from close() events rather than open() eve= nts).=20 > > >> I don't think we should run in the Linux 'dentry' direction, but hav= ing a=20 > > >> more robust translation service would be quite valuable. One commen= t: I=20 > > >> think we should continue to have a KPI which does a sleep-free trans= lation=20 > > >> to call, but with weaker semantics than one that is sleepable and ca= n query=20 > > >> for more robust reverse lookup. > > > > > > Okay, what about a name? > >=20 > > Oh, I do love a good bikeshed. I'm actually fine with any of these, bu= t=20 > > vn_fullpath_cache() sounds good to me. One of the cases I have in mind= is=20 > > path-based MAC policies, which will convert from a vnode to a path whil= e=20 > > holding the vnode lock -- if something is going to run around locking v= nodes=20 > > and doing VOP_READDIR's, that is not the time to do it. >=20 > I've duplicated vn_fullpath, vn_fullpath_global, and textvp_fullpath in > this latest version. The new (well, old) functions are named *_cache. > I even updated the vn_fullpath.9 man page. >=20 > http://www.marcuscom.com/downloads/vop_vptocnp_7.diff Main reason for vn_fullpath_cache() is to not sleep inside the function. I think this shall be reflected in the man page changes you did. I do not like having the old code pasted into the vfs_cache.c together with new implementation. I think that vn_fullpath1 can take a flag specifying whether to call the vop, and return ENOENT when call is disabled. This shall give the same effect without code bloat. --3h+hNn3PVp185ISI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkk/7PAACgkQC3+MBN1Mb4i5VwCguSB+Pak1B26C7oZZv86wlap+ ljYAnAgUky/jvrhfWd42/lIPc2/6SP4l =mFtC -----END PGP SIGNATURE----- --3h+hNn3PVp185ISI-- From owner-freebsd-arch@FreeBSD.ORG Wed Dec 10 23:23:17 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 E4742106564A; Wed, 10 Dec 2008 23:23:17 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 830738FC13; Wed, 10 Dec 2008 23:23:17 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id mBANOxIs062092; Wed, 10 Dec 2008 18:24:59 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Kostik Belousov In-Reply-To: <20081210162312.GO2038@deviant.kiev.zoral.com.ua> References: <1228667168.69753.16.camel@shumai.marcuscom.com> <20081207170354.GI18652@hoeg.nl> <1228670197.69753.24.camel@shumai.marcuscom.com> <1228784805.69132.66.camel@shumai.marcuscom.com> <1228894344.35477.40.camel@shumai.marcuscom.com> <20081210162312.GO2038@deviant.kiev.zoral.com.ua> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3S3t+uGpGV7anj5ggysm" Organization: FreeBSD, Inc. Date: Wed, 10 Dec 2008 18:23:13 -0500 Message-Id: <1228951393.39938.7.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Ed Schouten , Robert Watson , arch@FreeBSD.org 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: Wed, 10 Dec 2008 23:23:18 -0000 --=-3S3t+uGpGV7anj5ggysm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-12-10 at 18:23 +0200, Kostik Belousov wrote: > On Wed, Dec 10, 2008 at 02:32:24AM -0500, Joe Marcus Clarke wrote: > > On Tue, 2008-12-09 at 11:22 +0000, Robert Watson wrote: > > > On Mon, 8 Dec 2008, Joe Marcus Clarke wrote: > > >=20 > > > >> Just to give a general vote of "we need to do something here, whet= her the=20 > > > >> details are exactly these or not" -- having better object->path re= solution=20 > > > >> is quite important for audit, as well as if we want to adopt a fil= e system=20 > > > >> notification services along the lines of Apple's fsevents (which i= s=20 > > > >> path-centric and operates from close() events rather than open() e= vents).=20 > > > >> I don't think we should run in the Linux 'dentry' direction, but h= aving a=20 > > > >> more robust translation service would be quite valuable. One comm= ent: I=20 > > > >> think we should continue to have a KPI which does a sleep-free tra= nslation=20 > > > >> to call, but with weaker semantics than one that is sleepable and = can query=20 > > > >> for more robust reverse lookup. > > > > > > > > Okay, what about a name? > > >=20 > > > Oh, I do love a good bikeshed. I'm actually fine with any of these, = but=20 > > > vn_fullpath_cache() sounds good to me. One of the cases I have in mi= nd is=20 > > > path-based MAC policies, which will convert from a vnode to a path wh= ile=20 > > > holding the vnode lock -- if something is going to run around locking= vnodes=20 > > > and doing VOP_READDIR's, that is not the time to do it. > >=20 > > I've duplicated vn_fullpath, vn_fullpath_global, and textvp_fullpath in > > this latest version. The new (well, old) functions are named *_cache. > > I even updated the vn_fullpath.9 man page. > >=20 > > http://www.marcuscom.com/downloads/vop_vptocnp_7.diff >=20 > Main reason for vn_fullpath_cache() is to not sleep inside the function. > I think this shall be reflected in the man page changes you did. >=20 > I do not like having the old code pasted into the vfs_cache.c together > with new implementation. I think that vn_fullpath1 can take a flag > specifying whether to call the vop, and return ENOENT when call is > disabled. This shall give the same effect without code bloat. Of course. I should have thought of that. New diff is up. http://www.marcuscom.com/downloads/vop_vptocnp_8.diff Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-3S3t+uGpGV7anj5ggysm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAklAT2AACgkQb2iPiv4Uz4c6KgCaAlcgbg9sOAzh0h7abVKbt3GI BqAAn3ToyGEsjioQAaZ39ZVrq6Qi5nhE =pzmr -----END PGP SIGNATURE----- --=-3S3t+uGpGV7anj5ggysm-- From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 17:52:27 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 62AE51065676 for ; Thu, 11 Dec 2008 17:52:27 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 06B3C8FC14 for ; Thu, 11 Dec 2008 17:52:27 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 56BF21CE11; Thu, 11 Dec 2008 18:55:19 +0100 (CET) Date: Thu, 11 Dec 2008 18:55:19 +0100 From: Ed Schouten To: FreeBSD Arch Message-ID: <20081211175519.GD1176@hoeg.nl> References: <49381DD4.2000506@kasimir.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jCrbxBqMcLqd4mOl" Content-Disposition: inline In-Reply-To: <49381DD4.2000506@kasimir.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: What about strnlen(3)? 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: Thu, 11 Dec 2008 17:52:27 -0000 --jCrbxBqMcLqd4mOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, News flash: P1003.1 Issue 7 just got released. The spec seems to mention this routine: size_t strnlen(const char *s,size_t maxlen); Maybe we should add this one as well? --=20 Ed Schouten WWW: http://80386.nl/ --jCrbxBqMcLqd4mOl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklBVAcACgkQ52SDGA2eCwVhAwCfX0JGLOQ7/s0deIBWom3+NH5c yVcAniEc8f3jCau9zP85nV1TIDfwY68y =bICL -----END PGP SIGNATURE----- --jCrbxBqMcLqd4mOl-- From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 18:52:52 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 D9850106564A for ; Thu, 11 Dec 2008 18:52:52 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 95A8A8FC1D for ; Thu, 11 Dec 2008 18:52:52 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so507163ywe.13 for ; Thu, 11 Dec 2008 10:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HJd+06N4IHrq4HP0ITy535AJF7JYbZaEXInecyGFzyE=; b=bMRuMJ2AuYA0Co9Fly+B5n46K+RwrLrFUj9cbDDT/v2GHYrl51sOc6ziroJsdq+a+B OO42+k9/pM22O/lHYxSnl1mD98bKxsbGYZ9FH5v2xJRuP0HE6spp0fbs4EURcGjTFrOD 5m1KeR5Pr5ZZDF0Uhlu7ntW/bvpn1qgP6b938= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=egnaXK7Z1UKK/md8W6ZVQ54ySohHtikAV9CkeiCBY+q14WyJi3XU7t4RwKkfSnMFM3 Dwrh1U58D1+rGoH/mfYMytaaabXZRZQ7ETrAKCm6wdT+bL4XFGfBVs/JhJ0v2WQ8x6cT N5QzIsL0ALHx4ZKSMoDRAtMqcrYbMItyCchLE= Received: by 10.90.100.20 with SMTP id x20mr1719438agb.47.1229020066239; Thu, 11 Dec 2008 10:27:46 -0800 (PST) Received: by 10.90.91.14 with HTTP; Thu, 11 Dec 2008 10:27:46 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 18:27:46 +0000 From: pluknet To: "Ed Schouten" In-Reply-To: <20081211175519.GD1176@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49381DD4.2000506@kasimir.com> <20081211175519.GD1176@hoeg.nl> Cc: FreeBSD Arch Subject: Re: What about strnlen(3)? 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: Thu, 11 Dec 2008 18:52:52 -0000 2008/12/11 Ed Schouten : > Hello all, > > News flash: P1003.1 Issue 7 just got released. The spec seems to mention > this routine: > > size_t strnlen(const char *s,size_t maxlen); > > Maybe we should add this one as well? > And strnlen() is used by 3rd party software, such as GlusterFS. my 2c. -- wbr, pluknet From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 19:01:47 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 D91EB1065679 for ; Thu, 11 Dec 2008 19:01:47 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 497888FC17 for ; Thu, 11 Dec 2008 19:01:47 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DACF31CE11; Thu, 11 Dec 2008 20:04:36 +0100 (CET) Date: Thu, 11 Dec 2008 20:04:36 +0100 From: Ed Schouten To: FreeBSD Arch Message-ID: <20081211190436.GE1176@hoeg.nl> References: <49381DD4.2000506@kasimir.com> <20081211175519.GD1176@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WlEyl6ow+jlIgNUh" Content-Disposition: inline In-Reply-To: <20081211175519.GD1176@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Patch] strnlen(3) 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: Thu, 11 Dec 2008 19:01:47 -0000 --WlEyl6ow+jlIgNUh Content-Type: multipart/mixed; boundary="ytoMbUMiTKPMT3hY" Content-Disposition: inline --ytoMbUMiTKPMT3hY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, I've attached a patch, that adds strnlen(3) to libc. It also moves strndup(3) out of __BSD_VISIBLE. I'll see if it survives `make universe' and commit it soonish. Any comments? --=20 Ed Schouten WWW: http://80386.nl/ --ytoMbUMiTKPMT3hY Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="strnlen.diff" Content-Transfer-Encoding: quoted-printable Index: include/string.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- include/string.h (revision 185939) +++ include/string.h (working copy) @@ -95,8 +95,9 @@ char *strncat(char * __restrict, const char * __restrict, size_t); int strncmp(const char *, const char *, size_t) __pure; char *strncpy(char * __restrict, const char * __restrict, size_t); +char *strndup(const char *, size_t); +size_t strnlen(const char *, size_t) __pure; #if __BSD_VISIBLE -char *strndup(const char *, size_t); char *strnstr(const char *, const char *, size_t) __pure; #endif char *strpbrk(const char *, const char *) __pure; Index: lib/libc/string/Symbol.map =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/string/Symbol.map (revision 185939) +++ lib/libc/string/Symbol.map (working copy) @@ -82,6 +82,7 @@ flsll; memrchr; strndup; + strnlen; }; =20 FBSDprivate_1.0 { Index: lib/libc/string/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/string/Makefile.inc (revision 185939) +++ lib/libc/string/Makefile.inc (working copy) @@ -11,7 +11,7 @@ memcpy.c memmem.c memmove.c memset.c rindex.c stpcpy.c strcasecmp.c \ strcat.c strcasestr.c strchr.c strcmp.c strcoll.c strcpy.c strcspn.c \ strdup.c strerror.c strlcat.c strlcpy.c strlen.c strmode.c strncat.c \ - strncmp.c strncpy.c strndup.c strnstr.c \ + strncmp.c strncpy.c strndup.c strnlen.c strnstr.c \ strpbrk.c strrchr.c strsep.c strsignal.c strspn.c strstr.c strtok.c \ strxfrm.c swab.c wcscat.c wcschr.c wcscmp.c wcscoll.c wcscpy.c \ wcscspn.c wcsdup.c \ @@ -52,6 +52,7 @@ MLINKS+=3Dstrerror.3 perror.3 strerror.3 sys_errlist.3 strerror.3 sys_nerr= =2E3 MLINKS+=3Dstrerror.3 strerror_r.3 MLINKS+=3Dstrlcpy.3 strlcat.3 +MLINKS+=3Dstrlen.3 strnlen.3 MLINKS+=3Dstrtok.3 strtok_r.3 MLINKS+=3Dstrstr.3 strcasestr.3 MLINKS+=3Dstrstr.3 strnstr.3 Index: lib/libc/string/strnlen.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/string/strnlen.c (revision 0) +++ lib/libc/string/strnlen.c (revision 0) @@ -0,0 +1,40 @@ +/*- + * Copyright (c) 2008 Ed Schouten + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include + +size_t +strnlen(const char *str, size_t l) +{ + const char *s; + + for (s =3D str; l > 0 && *s !=3D '\0'; l--, s++); + + return (s - str); +} Index: lib/libc/string/strlen.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/string/strlen.3 (revision 185939) +++ lib/libc/string/strlen.3 (working copy) @@ -36,7 +36,8 @@ .Dt STRLEN 3 .Os .Sh NAME -.Nm strlen +.Nm strlen , +.Nm strnlen , .Nd find length of string .Sh LIBRARY .Lb libc @@ -44,21 +45,33 @@ .In string.h .Ft size_t .Fn strlen "const char *s" +.Ft size_t +.Fn strnlen "const char *s" "size_t maxlen" .Sh DESCRIPTION The .Fn strlen -function +and +.Fn strnlen +functions computes the length of the string .Fa s . +The +.Fn strnlen +function shall never examine more than +.Fa maxlen +bytes. .Sh RETURN VALUES The .Fn strlen -function -returns -the number of characters that precede the -terminating +and +.Fn strnlen +functions return the number of characters that precede the terminating .Dv NUL character. +In addition, the +.Fn strnlen +function never returns a value greater than +.Fa maxlen . .Sh SEE ALSO .Xr string 3 .Sh STANDARDS --ytoMbUMiTKPMT3hY-- --WlEyl6ow+jlIgNUh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklBZEQACgkQ52SDGA2eCwV9WgCdF4mWfSaRiLuKgoQh8evltTvC VvYAn0GcytWwYl4/u9cqKqhSVah+1me1 =6WmV -----END PGP SIGNATURE----- --WlEyl6ow+jlIgNUh-- From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 19:34:24 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 6F6881065670 for ; Thu, 11 Dec 2008 19:34:24 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by mx1.freebsd.org (Postfix) with ESMTP id 22F838FC18 for ; Thu, 11 Dec 2008 19:34:23 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by mail-gx0-f12.google.com with SMTP id 5so591195gxk.19 for ; Thu, 11 Dec 2008 11:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=UpqXOQF5+clfcXjZSO7oXsbVAVOBSl9cql2xOcnP+oA=; b=T2lU1MZHraSjKOaXBUUqDJ+yLrZeQsVwXU3p2TSQDKbEbqDzQUGz+VjUzAYcBP/avW Rulb9aIkgtuLR+81fQapjOka1TJ9lFM18a4UMfRmWQBJIXTLqixzHZJ8rYFsJtPDdj9L nHxFONqIMXOs5dcCdiofIJ5eDAYyeBWbEUTz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Fe69Mft5gHwaF4VqznBUCf2Y1rlp6ZMUh7FlIg0IJzD9ii0xNahGI1squUePylccQc mjdWXsxxs9omez0t35Ov0lsdZ/iRyoJmomyqxEMajQoNZyH/GsjkcxcGyPlF3CnRhnCN 67xicvAycymxmzQJKK4ZRQm4j7mM5T2vk1/34= Received: by 10.90.70.15 with SMTP id s15mr1780861aga.82.1229024054607; Thu, 11 Dec 2008 11:34:14 -0800 (PST) Received: by 10.90.91.14 with HTTP; Thu, 11 Dec 2008 11:34:14 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 22:34:14 +0300 From: pluknet To: "Ed Schouten" In-Reply-To: <20081211190436.GE1176@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49381DD4.2000506@kasimir.com> <20081211175519.GD1176@hoeg.nl> <20081211190436.GE1176@hoeg.nl> Cc: FreeBSD Arch Subject: Re: [Patch] strnlen(3) 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: Thu, 11 Dec 2008 19:34:24 -0000 2008/12/11 Ed Schouten : > Hello all, > > I've attached a patch, that adds strnlen(3) to libc. It also moves > strndup(3) out of __BSD_VISIBLE. I'll see if it survives `make universe' > and commit it soonish. Any comments? > btw, we already have strnlen under BSD license in the tree (in contribs), which is more optimized (uses one less instruction). > -- > Ed Schouten > WWW: http://80386.nl/ > -- wbr, pluknet From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 19:57:47 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 66012106564A for ; Thu, 11 Dec 2008 19:57:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1F58FC16 for ; Thu, 11 Dec 2008 19:57:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LArfM-0002UK-Kc; Thu, 11 Dec 2008 21:57:44 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBBJvfXc068295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 21:57:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBBJvfT8043290; Thu, 11 Dec 2008 21:57:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBBJvfgv043289; Thu, 11 Dec 2008 21:57:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Dec 2008 21:57:41 +0200 From: Kostik Belousov To: Ed Schouten Message-ID: <20081211195741.GW2038@deviant.kiev.zoral.com.ua> References: <49381DD4.2000506@kasimir.com> <20081211175519.GD1176@hoeg.nl> <20081211190436.GE1176@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UaIp6+ubhcbWp687" Content-Disposition: inline In-Reply-To: <20081211190436.GE1176@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LArfM-0002UK-Kc df5e49348b3b31d6758f26b057dc6e43 X-Terabit: YES Cc: FreeBSD Arch Subject: Re: [Patch] strnlen(3) 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: Thu, 11 Dec 2008 19:57:47 -0000 --UaIp6+ubhcbWp687 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 11, 2008 at 08:04:36PM +0100, Ed Schouten wrote: > Hello all, >=20 > I've attached a patch, that adds strnlen(3) to libc. It also moves > strndup(3) out of __BSD_VISIBLE. I'll see if it survives `make universe' > and commit it soonish. Any comments? strndup shall stay under __BSD_VISIBLE, and strnlen declaration shall go unto this define too. Not doing this will pollute namespace for the POSIX revisions we are (partially) trying to support. I think that style recommends to put empty statements constituting loop body on the separate line, properly indented. --UaIp6+ubhcbWp687 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklBcLQACgkQC3+MBN1Mb4hc0QCfRaQhtGxsWOHsh5Q+Dycz480E lwIAoMk09aA6jKHatnF0ugevMqOw6jK+ =hUm/ -----END PGP SIGNATURE----- --UaIp6+ubhcbWp687-- From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 23:48:09 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 323121065673 for ; Thu, 11 Dec 2008 23:48:09 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep18-int.chello.at (viefep22-int.chello.at [62.179.121.42]) by mx1.freebsd.org (Postfix) with ESMTP id 76BF28FC13 for ; Thu, 11 Dec 2008 23:48:08 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from edge01.upc.biz ([192.168.13.236]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20081211233253.QHCG2201.viefep20-int.chello.at@edge01.upc.biz>; Fri, 12 Dec 2008 00:32:53 +0100 Received: from lizard.fafoe.narf.at ([213.47.85.26]) by edge01.upc.biz with edge id pzYr1a02v0a5KZh01zYszc; Fri, 12 Dec 2008 00:32:53 +0100 X-SourceIP: 213.47.85.26 Received: by lizard.fafoe.narf.at (Postfix, from userid 1001) id AE192BAD3; Fri, 12 Dec 2008 00:32:45 +0100 (CET) Date: Fri, 12 Dec 2008 00:32:45 +0100 From: Stefan Farfeleder To: Kostik Belousov Message-ID: <20081211233244.GA1414@lizard.fafoe.narf.at> References: <49381DD4.2000506@kasimir.com> <20081211175519.GD1176@hoeg.nl> <20081211190436.GE1176@hoeg.nl> <20081211195741.GW2038@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081211195741.GW2038@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Ed Schouten , FreeBSD Arch Subject: Re: [Patch] strnlen(3) 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: Thu, 11 Dec 2008 23:48:09 -0000 On Thu, Dec 11, 2008 at 09:57:41PM +0200, Kostik Belousov wrote: > On Thu, Dec 11, 2008 at 08:04:36PM +0100, Ed Schouten wrote: > > Hello all, > > > > I've attached a patch, that adds strnlen(3) to libc. It also moves > > strndup(3) out of __BSD_VISIBLE. I'll see if it survives `make universe' > > and commit it soonish. Any comments? > strndup shall stay under __BSD_VISIBLE, and strnlen declaration shall > go unto this define too. Not doing this will pollute namespace > for the POSIX revisions we are (partially) trying to support. It should propably be inside #if __POSIX_VISIBLE >= 2008xx for a suitable value of 2008xx for P1003.1 Issue 7. From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 10:10:12 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 8B3CC1065675 for ; Fri, 12 Dec 2008 10:10:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 25D6B8FC1E for ; Fri, 12 Dec 2008 10:10:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LB4yI-000AFV-70; Fri, 12 Dec 2008 12:10:10 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBCAA66w041805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 12:10:07 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBCAA60K026978; Fri, 12 Dec 2008 12:10:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBCAA68s026976; Fri, 12 Dec 2008 12:10:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Dec 2008 12:10:06 +0200 From: Kostik Belousov To: Stefan Farfeleder Message-ID: <20081212101006.GZ2038@deviant.kiev.zoral.com.ua> References: <49381DD4.2000506@kasimir.com> <20081211175519.GD1176@hoeg.nl> <20081211190436.GE1176@hoeg.nl> <20081211195741.GW2038@deviant.kiev.zoral.com.ua> <20081211233244.GA1414@lizard.fafoe.narf.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v3gsnnLXiLKXzTq3" Content-Disposition: inline In-Reply-To: <20081211233244.GA1414@lizard.fafoe.narf.at> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LB4yI-000AFV-70 078a7d6d1014a1f32dabdc20b48b1d47 X-Terabit: YES Cc: Ed Schouten , FreeBSD Arch Subject: Re: [Patch] strnlen(3) 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: Fri, 12 Dec 2008 10:10:12 -0000 --v3gsnnLXiLKXzTq3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 12, 2008 at 12:32:45AM +0100, Stefan Farfeleder wrote: > On Thu, Dec 11, 2008 at 09:57:41PM +0200, Kostik Belousov wrote: > > On Thu, Dec 11, 2008 at 08:04:36PM +0100, Ed Schouten wrote: > > > Hello all, > > >=20 > > > I've attached a patch, that adds strnlen(3) to libc. It also moves > > > strndup(3) out of __BSD_VISIBLE. I'll see if it survives `make univer= se' > > > and commit it soonish. Any comments? > > strndup shall stay under __BSD_VISIBLE, and strnlen declaration shall > > go unto this define too. Not doing this will pollute namespace > > for the POSIX revisions we are (partially) trying to support. >=20 > It should propably be inside #if __POSIX_VISIBLE >=3D 2008xx for a > suitable value of 2008xx for P1003.1 Issue 7. Exactly. Since the 2008xx infrastructure work is not done yet, we shall keep it in BSD namespace (that is enabled by default). --v3gsnnLXiLKXzTq3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklCOHoACgkQC3+MBN1Mb4gpEACeKaLtbrNjoAX/00eY5lkpKrlC 02gAn36Wp3HEn2CZfuiP/GvvafFWOtBr =N7Hd -----END PGP SIGNATURE----- --v3gsnnLXiLKXzTq3--