From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 01:23:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 851B7F07 for ; Sun, 2 Nov 2014 01:23:15 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5044CFB1 for ; Sun, 2 Nov 2014 01:23:14 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-239-104.lns20.per1.internode.on.net [121.45.239.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA21NAEJ016786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 1 Nov 2014 18:23:13 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54558778.7050500@freebsd.org> Date: Sun, 02 Nov 2014 09:23:04 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Kientzle , Rick Macklem Subject: Re: how to kernel printf a int64_t? References: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> <97A82163-E78D-457E-B649-B243B41A6C6F@kientzle.com> In-Reply-To: <97A82163-E78D-457E-B649-B243B41A6C6F@kientzle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 01:23:15 -0000 On 10/31/14, 1:09 PM, Tim Kientzle wrote: > On Oct 30, 2014, at 2:01 PM, Rick Macklem wrote: > >> Hi, >> >> I feel kinda dumb asking this, but... >> int64_t i; >> >> printf("%qd\n", (u_quad_t)i); >> >> works but looks dorky, to put it technically;-). >> Is there a better way to printf() a int64_t in the kernel? > I often use the following to print large integers: > > printf(�%jd\n�, (intmax_t)i); the "cannonical' way is to use PRIu64 and friends, but some people seem to have a problem with doing that. > > Tim > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 01:46:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4CE240B; Sun, 2 Nov 2014 01:46:33 +0000 (UTC) Received: from mail.akips.com (mail.akips.com [65.19.130.19]) by mx1.freebsd.org (Postfix) with ESMTP id 904F620D; Sun, 2 Nov 2014 01:46:33 +0000 (UTC) Received: from akips.com (CPE-120-146-191-2.static.qld.bigpond.net.au [120.146.191.2]) by mail.akips.com (Postfix) with ESMTPSA id 0A71C16; Sun, 2 Nov 2014 11:46:25 +1000 (EST) Date: Sun, 2 Nov 2014 11:46:14 +1000 From: Paul Koch To: Julian Elischer Subject: Re: how to kernel printf a int64_t? Message-ID: <20141102114614.38aa9034@akips.com> In-Reply-To: <54558778.7050500@freebsd.org> References: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> <97A82163-E78D-457E-B649-B243B41A6C6F@kientzle.com> <54558778.7050500@freebsd.org> Organization: AKIPS X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on host1.akips.com X-Mailman-Approved-At: Sun, 02 Nov 2014 02:02:11 +0000 Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 01:46:33 -0000 On Sun, 02 Nov 2014 09:23:04 +0800 Julian Elischer wrote: > On 10/31/14, 1:09 PM, Tim Kientzle wrote: > > On Oct 30, 2014, at 2:01 PM, Rick Macklem wrote: > > > >> Hi, > >> > >> I feel kinda dumb asking this, but... > >> int64_t i; > >> > >> printf("%qd\n", (u_quad_t)i); > >> > >> works but looks dorky, to put it technically;-). > >> Is there a better way to printf() a int64_t in the kernel? > > I often use the following to print large integers: > > > > printf(�%jd\n�, (intmax_t)i); > > the "cannonical' way is to use PRIu64 and friends, but some people > seem to have a problem with doing that. We've always used the PRIxxx types when coding for both 32/64 platforms, but it would have been really nice to have a standard way for time_t. Something like PRItt Paul. -- Paul Koch | Founder, CEO AKIPS Network Monitor http://www.akips.com Brisbane, Australia From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 02:14:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 152D0C23; Sun, 2 Nov 2014 02:14:47 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id ACB18689; Sun, 2 Nov 2014 02:14:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAPqSVVSDaFve/2dsb2JhbABcg2JYBIMCyjcKhnlUAoEqAQEBAQF9hAIBAQEDAQEBASArIAsbGAICDRkCKQEJJgYPBAEcBIgXCQ21H5QKAQEBAQYBAQEBAQEBARqBLY8SAQEbATMHgneBVAWWaYQShHSLC4lXhBQhLweBCDmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,295,1413259200"; d="scan'208";a="163915789" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 01 Nov 2014 22:14:45 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 027BBB3F91; Sat, 1 Nov 2014 22:14:45 -0400 (EDT) Date: Sat, 1 Nov 2014 22:14:45 -0400 (EDT) From: Rick Macklem To: Julian Elischer Message-ID: <604180572.3888597.1414894484998.JavaMail.root@uoguelph.ca> In-Reply-To: <54558778.7050500@freebsd.org> Subject: Re: how to kernel printf a int64_t? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 02:14:47 -0000 Julian Elischer wrote: >=20 > On 10/31/14, 1:09 PM, Tim Kientzle wrote: >=20 >=20 > On Oct 30, 2014, at 2:01 PM, Rick Macklem > wrote: >=20 > Hi, >=20 > I feel kinda dumb asking this, but... > int64_t i; >=20 > printf("%qd\n", (u_quad_t)i); >=20 > works but looks dorky, to put it technically;-). > Is there a better way to printf() a int64_t in the kernel? I often > use the following to print large integers: >=20 > printf(=E2=80=9C%jd\n=E2=80=9D, (intmax_t)i); the "cannonical' way is= to use > PRIu64 and friends, but some people seem to have a problem with > doing that. >=20 Ok, so now I need to ask another dumb question. How do you do this in the kernel? (I can see them defines in , but including that doesn't help, which isn't surprising since PRIu64 is in a string and won't be recognized as a macro.) Oh, and is intmax_t going to be int64_t on all arches? Thanks, rick >=20 >=20 > Tim >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To > unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" >=20 From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 03:20:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAF085AB for ; Sun, 2 Nov 2014 03:20:15 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F2D3C79 for ; Sun, 2 Nov 2014 03:20:15 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-239-104.lns20.per1.internode.on.net [121.45.239.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA23KAos017098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 1 Nov 2014 20:20:13 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5455A2E3.40808@freebsd.org> Date: Sun, 02 Nov 2014 11:20:03 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: how to kernel printf a int64_t? References: <604180572.3888597.1414894484998.JavaMail.root@uoguelph.ca> In-Reply-To: <604180572.3888597.1414894484998.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 03:20:15 -0000 On 11/2/14, 10:14 AM, Rick Macklem wrote: > Julian Elischer wrote: >> On 10/31/14, 1:09 PM, Tim Kientzle wrote: >> >> >> On Oct 30, 2014, at 2:01 PM, Rick Macklem >> wrote: >> >> Hi, >> >> I feel kinda dumb asking this, but... >> int64_t i; >> >> printf("%qd\n", (u_quad_t)i); >> >> works but looks dorky, to put it technically;-). >> Is there a better way to printf() a int64_t in the kernel? I often >> use the following to print large integers: >> >> printf(“%jd\n”, (intmax_t)i); the "cannonical' way is to use >> PRIu64 and friends, but some people seem to have a problem with >> doing that. >> > Ok, so now I need to ask another dumb question. > How do you do this in the kernel? > (I can see them defines in , but including that > doesn't help, which isn't surprising since PRIu64 is in a string > and won't be recognized as a macro.) you use it with string concatenation. like: printf (" this is a 64 it unsigned value: %" PRIu64 " and I just printed it\n", thingy64); After substitution the compiler sees " this is a 64 it unsigned value: %" "llu" " and I just printed it\n" which simplifies to: " this is a 64 it unsigned value: %llu and I just printed it\n" due to concatenation. (note I didn't actually look what PRIu64 evaluates to) > > Oh, and is intmax_t going to be int64_t on all arches? > > Thanks, rick > >> >> Tim >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To >> unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > > From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 03:58:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A6E7A64; Sun, 2 Nov 2014 03:58:33 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A904F62; Sun, 2 Nov 2014 03:58:32 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XkmJC-000HSJ-Vc; Sun, 02 Nov 2014 03:58:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA23wTap088564; Sat, 1 Nov 2014 21:58:29 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ves+QlHyRzfeKnB31PbMk X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: how to kernel printf a int64_t? From: Ian Lepore To: Julian Elischer In-Reply-To: <5455A2E3.40808@freebsd.org> References: <604180572.3888597.1414894484998.JavaMail.root@uoguelph.ca> <5455A2E3.40808@freebsd.org> Content-Type: text/plain; charset="iso-8859-13" Date: Sat, 01 Nov 2014 21:58:29 -0600 Message-ID: <1414900709.17308.243.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sA23wTap088564 Cc: Freebsd hackers list , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 03:58:33 -0000 On Sun, 2014-11-02 at 11:20 +0800, Julian Elischer wrote: > On 11/2/14, 10:14 AM, Rick Macklem wrote: > > Julian Elischer wrote: > >> On 10/31/14, 1:09 PM, Tim Kientzle wrote: > >> > >> > >> On Oct 30, 2014, at 2:01 PM, Rick Macklem > >> wrote: > >> > >> Hi, > >> > >> I feel kinda dumb asking this, but... > >> int64_t i; > >> > >> printf("%qd\n", (u_quad_t)i); > >> > >> works but looks dorky, to put it technically;-). > >> Is there a better way to printf() a int64_t in the kernel? I often > >> use the following to print large integers: > >> > >> printf(=B4%jd\n=A1, (intmax_t)i); the "cannonical' way is to us= e > >> PRIu64 and friends, but some people seem to have a problem with > >> doing that. > >> > > Ok, so now I need to ask another dumb question. > > How do you do this in the kernel? > > (I can see them defines in , but including that > > doesn't help, which isn't surprising since PRIu64 is in a string > > and won't be recognized as a macro.) >=20 > you use it with string concatenation. > like: >=20 > printf (" this is a 64 it unsigned value: %" PRIu64 " and I just=20 > printed it\n", thingy64); >=20 > After substitution the compiler sees > " this is a 64 it unsigned value: %" "llu" " and I just printed it\n" > which simplifies to: > " this is a 64 it unsigned value: %llu and I just printed it\n" >=20 > due to concatenation. (note I didn't actually look what PRIu64=20 > evaluates to) >=20 >=20 Which is exactly the explanation for why "some people seem to have a problem with doing that." "Some people" would be "anyone who thinks it should be possible to read code as well as write it." This may be more correct in some pedantic sense, but %j and a cast is more readable. -- Ian > > > > Oh, and is intmax_t going to be int64_t on all arches? > > > > Thanks, rick > > > >> > >> Tim > >> > >> _______________________________________________ > >> freebsd-hackers@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To > >> unsubscribe, send any mail to > >> "freebsd-hackers-unsubscribe@freebsd.org" > >> > > > > >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 12:00:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5ECD4B63; Sun, 2 Nov 2014 12:00:46 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1D63C8D; Sun, 2 Nov 2014 12:00:45 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so8685189wgh.11 for ; Sun, 02 Nov 2014 04:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=7ZeAiCXCfcp6EGwfAVMpk4VVDi/66FmgTYWmp/Egh4U=; b=teYt5An5lyn/etqOBt+AdzZ9daF0FbMYyw0nkG7Z9wT4b2/w77jD/EX9DnuHXhyh44 0lzK3kWobcPXtIU59811nAnfbViuK64kWgPCJbbe8nmiagbgYE20WyRjEKtOr6xGC+GZ 329xhIXs8+WZEUOtVEKp/+RXDYro8CdyGmGx17VuUilgVG6GKmbtW0wSpfFlx2ScsyC6 XCG8Gm9bSFH0Wbxqjp8Hfr0zPjAPrZ4DoLq+SeuXQlTUAWm4X976tJlVS3U6x6H0/6tI Samy+RDXdkZFB+LicK21t/SOX3R6PrTNm6z9HkNsApJSih/5Olp8a6J6wjeNeW7lSa03 bKRA== X-Received: by 10.194.76.101 with SMTP id j5mr28529379wjw.57.1414929644076; Sun, 02 Nov 2014 04:00:44 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id lm9sm18377545wjc.45.2014.11.02.04.00.42 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 02 Nov 2014 04:00:43 -0800 (PST) Date: Sun, 2 Nov 2014 13:00:40 +0100 From: Mateusz Guzik To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: junior kernel tasks Message-ID: <20141102120040.GA29497@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20141025204536.GD19066@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141025204536.GD19066@dft-labs.eu> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 12:00:46 -0000 On Sat, Oct 25, 2014 at 10:45:36PM +0200, Mateusz Guzik wrote: > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. > > https://wiki.freebsd.org/JuniorJobs > > It is assumed you know how to obtain sources and build the kernel. > > What you can get in return: > - your own code in FreeBSD tree > - eternal glory [1] > - fun [2] > > If you are not interested, but know someone who does, please pass it > down. > > [1] - not really, no > [2] - well, I guess that's subjective, so that's not a "no" > There are some new tasks on the list. Go ahead, take your pick. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 12:48:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B7EA57B; Sun, 2 Nov 2014 12:48:20 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3D57B103; Sun, 2 Nov 2014 12:48:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEACYnVlSDaFve/2dsb2JhbABcg2JYBIMCygcKhnlUAoEmAQEBAQF9hAMBAQQBAQEgKyALGxgCAg0ZAikBCSYGCAcEARwEiCANtEyUFgEBAQcBAQEBAQEBARqBLY8SAQEbATMHgneBVAWLdopzhBKENz2GQoRJhU6ECYQWHy8HgQg5gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,295,1413259200"; d="scan'208";a="165325700" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 02 Nov 2014 07:48:11 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9BB84B40D7; Sun, 2 Nov 2014 07:48:11 -0500 (EST) Date: Sun, 2 Nov 2014 07:48:11 -0500 (EST) From: Rick Macklem To: Ian Lepore Message-ID: <1123726553.4004621.1414932491616.JavaMail.root@uoguelph.ca> In-Reply-To: <1414900709.17308.243.camel@revolution.hippie.lan> Subject: Re: how to kernel printf a int64_t? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 12:48:20 -0000 Ian Lepore wrote: > On Sun, 2014-11-02 at 11:20 +0800, Julian Elischer wrote: > > On 11/2/14, 10:14 AM, Rick Macklem wrote: > > > Julian Elischer wrote: > > >> On 10/31/14, 1:09 PM, Tim Kientzle wrote: > > >> > > >> > > >> On Oct 30, 2014, at 2:01 PM, Rick Macklem > > >> wrote: > > >> > > >> Hi, > > >> > > >> I feel kinda dumb asking this, but... > > >> int64_t i; > > >> > > >> printf("%qd\n", (u_quad_t)i); > > >> > > >> works but looks dorky, to put it technically;-). > > >> Is there a better way to printf() a int64_t in the kernel? I > > >> often > > >> use the following to print large integers: > > >> > > >> printf(=E2=80=9C%jd\n=E2=80=9D, (intmax_t)i); the "cannonical' = way is to > > >> use > > >> PRIu64 and friends, but some people seem to have a problem > > >> with > > >> doing that. > > >> > > > Ok, so now I need to ask another dumb question. > > > How do you do this in the kernel? > > > (I can see them defines in , but including > > > that > > > doesn't help, which isn't surprising since PRIu64 is in a > > > string > > > and won't be recognized as a macro.) > >=20 > > you use it with string concatenation. > > like: > >=20 > > printf (" this is a 64 it unsigned value: %" PRIu64 " and I > > just > > printed it\n", thingy64); > >=20 > > After substitution the compiler sees > > " this is a 64 it unsigned value: %" "llu" " and I just printed > > it\n" > > which simplifies to: > > " this is a 64 it unsigned value: %llu and I just printed it\n" > >=20 > > due to concatenation. (note I didn't actually look what PRIu64 > > evaluates to) > >=20 > >=20 >=20 > Which is exactly the explanation for why "some people seem to have a > problem with doing that." "Some people" would be "anyone who thinks > it > should be possible to read code as well as write it." This may be > more > correct in some pedantic sense, but %j and a cast is more readable. >=20 Yes, thanks. I'll admit to thinking exactly the same thing. I guess I'll use %j. Thanks everyone for your help, rick > -- Ian >=20 > > > > > > Oh, and is intmax_t going to be int64_t on all arches? > > > > > > Thanks, rick > > > > > >> > > >> Tim > > >> > > >> _______________________________________________ > > >> freebsd-hackers@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To > > >> unsubscribe, send any mail to > > >> "freebsd-hackers-unsubscribe@freebsd.org" > > >> > > > > > > > >=20 > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" > >=20 >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" >=20 From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 16:04:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7CF93C2; Sun, 2 Nov 2014 16:04:32 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6647380; Sun, 2 Nov 2014 16:04:31 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-239-104.lns20.per1.internode.on.net [121.45.239.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA2G4RvG019224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 2 Nov 2014 08:04:29 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54565604.2030208@freebsd.org> Date: Mon, 03 Nov 2014 00:04:20 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rick Macklem , Ian Lepore Subject: Re: how to kernel printf a int64_t? References: <1123726553.4004621.1414932491616.JavaMail.root@uoguelph.ca> In-Reply-To: <1123726553.4004621.1414932491616.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 16:04:33 -0000 On 11/2/14, 8:48 PM, Rick Macklem wrote: > Ian Lepore wrote: >> On Sun, 2014-11-02 at 11:20 +0800, Julian Elischer wrote: >>> On 11/2/14, 10:14 AM, Rick Macklem wrote: >>>> Julian Elischer wrote: >>>>> On 10/31/14, 1:09 PM, Tim Kientzle wrote: >>>>> >>>>> >>>>> On Oct 30, 2014, at 2:01 PM, Rick Macklem >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I feel kinda dumb asking this, but... >>>>> int64_t i; >>>>> >>>>> printf("%qd\n", (u_quad_t)i); >>>>> >>>>> works but looks dorky, to put it technically;-). >>>>> Is there a better way to printf() a int64_t in the kernel? I >>>>> often >>>>> use the following to print large integers: >>>>> >>>>> printf(“%jd\n”, (intmax_t)i); the "cannonical' way is to >>>>> use >>>>> PRIu64 and friends, but some people seem to have a problem >>>>> with >>>>> doing that. >>>>> >>>> Ok, so now I need to ask another dumb question. >>>> How do you do this in the kernel? >>>> (I can see them defines in , but including >>>> that >>>> doesn't help, which isn't surprising since PRIu64 is in a >>>> string >>>> and won't be recognized as a macro.) >>> you use it with string concatenation. >>> like: >>> >>> printf (" this is a 64 it unsigned value: %" PRIu64 " and I >>> just >>> printed it\n", thingy64); >>> >>> After substitution the compiler sees >>> " this is a 64 it unsigned value: %" "llu" " and I just printed >>> it\n" >>> which simplifies to: >>> " this is a 64 it unsigned value: %llu and I just printed it\n" >>> >>> due to concatenation. (note I didn't actually look what PRIu64 >>> evaluates to) >>> >>> >> Which is exactly the explanation for why "some people seem to have a >> problem with doing that." "Some people" would be "anyone who thinks >> it >> should be possible to read code as well as write it." This may be >> more >> correct in some pedantic sense, but %j and a cast is more readable. >> > Yes, thanks. I'll admit to thinking exactly the same thing. > I guess I'll use %j. then your code could be wrong in some cases.. PRIu64 specifies that the value will always be 64 bits (unsigned) on every architecture. If that's NOT true then yes, use a type (e.g. %d) that varies here and there. If your value will ALWAYS be 64 but then PRIu64 describes what it is much better than %j, because you need to know what %j expects on every architecture your code may ever run on. In my own opinion, PRIu64 is much more readable than %j because the size and expected signed/unsigned characterisitics are right there, where %randomletter is exactly that.. completely random, requiring that the reader go consult a man page first before reading code for any given architecture. > > Thanks everyone for your help, rick > >> -- Ian >> >>>> Oh, and is intmax_t going to be int64_t on all arches? >>>> >>>> Thanks, rick >>>> >>>>> Tim >>>>> >>>>> _______________________________________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To >>>>> unsubscribe, send any mail to >>>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>>> >>>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > > From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 16:08:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB3CA80E; Sun, 2 Nov 2014 16:08:48 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BEAE03D3; Sun, 2 Nov 2014 16:08:48 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-239-104.lns20.per1.internode.on.net [121.45.239.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA2G8i56019255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 2 Nov 2014 08:08:46 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54565706.3030103@freebsd.org> Date: Mon, 03 Nov 2014 00:08:38 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: how to kernel printf a int64_t? References: <604180572.3888597.1414894484998.JavaMail.root@uoguelph.ca> <5455A2E3.40808@freebsd.org> <1414900709.17308.243.camel@revolution.hippie.lan> In-Reply-To: <1414900709.17308.243.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-13; format=flowed Content-Transfer-Encoding: 7bit Cc: Freebsd hackers list , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 16:08:49 -0000 On 11/2/14, 11:58 AM, Ian Lepore wrote: > On Sun, 2014-11-02 at 11:20 +0800, Julian Elischer wrote: >> > Which is exactly the explanation for why "some people seem to have a > problem with doing that." "Some people" would be "anyone who thinks it > should be possible to read code as well as write it." This may be more > correct in some pedantic sense, but %j and a cast is more readable. Actually I don't believe that to be true, because casting can actually change the value. (truncation, sign change etc.) If you really want to be sure to see what you should. then use PRImumble... or be sure of what printf is going to do on every architecture your code is going to ever run on in the future.. > -- Ian > > > > > From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 16:35:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96938E0D; Sun, 2 Nov 2014 16:35:49 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56B44870; Sun, 2 Nov 2014 16:35:48 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xky7y-000LO6-1a; Sun, 02 Nov 2014 16:35:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA2GZf1T089792; Sun, 2 Nov 2014 09:35:41 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+u57BPOU90azeREyMClh0B X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: how to kernel printf a int64_t? From: Ian Lepore To: Julian Elischer In-Reply-To: <54565604.2030208@freebsd.org> References: <1123726553.4004621.1414932491616.JavaMail.root@uoguelph.ca> <54565604.2030208@freebsd.org> Content-Type: text/plain; charset="iso-8859-13" Date: Sun, 02 Nov 2014 09:35:40 -0700 Message-ID: <1414946140.67444.0.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sA2GZf1T089792 Cc: Freebsd hackers list , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 16:35:49 -0000 On Mon, 2014-11-03 at 00:04 +0800, Julian Elischer wrote:=20 > On 11/2/14, 8:48 PM, Rick Macklem wrote: > > Ian Lepore wrote: > >> On Sun, 2014-11-02 at 11:20 +0800, Julian Elischer wrote: > >>> On 11/2/14, 10:14 AM, Rick Macklem wrote: > >>>> Julian Elischer wrote: > >>>>> On 10/31/14, 1:09 PM, Tim Kientzle wrote: > >>>>> > >>>>> > >>>>> On Oct 30, 2014, at 2:01 PM, Rick Macklem > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I feel kinda dumb asking this, but... > >>>>> int64_t i; > >>>>> > >>>>> printf("%qd\n", (u_quad_t)i); > >>>>> > >>>>> works but looks dorky, to put it technically;-). > >>>>> Is there a better way to printf() a int64_t in the kernel? I > >>>>> often > >>>>> use the following to print large integers: > >>>>> > >>>>> printf(=B4%jd\n=A1, (intmax_t)i); the "cannonical' way is t= o > >>>>> use > >>>>> PRIu64 and friends, but some people seem to have a problem > >>>>> with > >>>>> doing that. > >>>>> > >>>> Ok, so now I need to ask another dumb question. > >>>> How do you do this in the kernel? > >>>> (I can see them defines in , but including > >>>> that > >>>> doesn't help, which isn't surprising since PRIu64 is in a > >>>> string > >>>> and won't be recognized as a macro.) > >>> you use it with string concatenation. > >>> like: > >>> > >>> printf (" this is a 64 it unsigned value: %" PRIu64 " and I > >>> just > >>> printed it\n", thingy64); > >>> > >>> After substitution the compiler sees > >>> " this is a 64 it unsigned value: %" "llu" " and I just printed > >>> it\n" > >>> which simplifies to: > >>> " this is a 64 it unsigned value: %llu and I just printed it\n" > >>> > >>> due to concatenation. (note I didn't actually look what PRIu64 > >>> evaluates to) > >>> > >>> > >> Which is exactly the explanation for why "some people seem to have a > >> problem with doing that." "Some people" would be "anyone who thinks > >> it > >> should be possible to read code as well as write it." This may be > >> more > >> correct in some pedantic sense, but %j and a cast is more readable. > >> > > Yes, thanks. I'll admit to thinking exactly the same thing. > > I guess I'll use %j. > then your code could be wrong in some cases.. >=20 The recommendation was "%j and a cast" not just %j. The cast will ensure that the size of the argument matches the size of the format. > PRIu64 specifies that the value will always be 64 bits (unsigned) on=20 > every architecture. > If that's NOT true then yes, use a type (e.g. %d) that varies here and=20 > there. > If your value will ALWAYS be 64 but then PRIu64 describes what it is=20 > much better than > %j, because you need to know what %j expects on every architecture your > code may ever run on. >=20 It is well-known what the %j size modifier expects on every architecture: the size of a value of type [u]intmax_t, which is what the corresponding argument cast provides. It is a given that [u]intmax_t is able to represent all other integer types of the corresponding signedness. > In my own opinion, PRIu64 is much more readable than %j because the siz= e > and expected signed/unsigned characterisitics are right there, where > %randomletter is exactly that.. completely random, requiring that the=20 > reader go > consult a man page first before reading code for any given architecture. >=20 I'm willing to be proven wrong that %j and the corresponding [u]intmax_t cast will provide the wrong result in some case. But the proof has to be in the form of something other than "I disagree with you on which one is more readable". You seem to be conflating correctness of operation with stylistic opinion in your reply (sorry if that's not your intent and the conflation is only in my head). -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 17:23:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF176F18; Sun, 2 Nov 2014 17:23:51 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87658C7C; Sun, 2 Nov 2014 17:23:50 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id sA2HNmTe023456; Sun, 2 Nov 2014 17:23:48 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.100] (gateway.kientzle.com [192.168.1.65]) by kientzle.com with SMTP id 4njizintkpcasucim67574te8a; Sun, 02 Nov 2014 17:23:48 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: how to kernel printf a int64_t? From: Tim Kientzle In-Reply-To: <20141102114614.38aa9034@akips.com> Date: Sun, 2 Nov 2014 09:23:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3E8C7E0D-5858-4BFF-8C09-FAA68200B988@kientzle.com> References: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> <97A82163-E78D-457E-B649-B243B41A6C6F@kientzle.com> <54558778.7050500@freebsd.org> <20141102114614.38aa9034@akips.com> To: Paul Koch X-Mailer: Apple Mail (2.1990.1) Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 17:23:51 -0000 > On Nov 1, 2014, at 6:46 PM, Paul Koch wrote: >=20 > On Sun, 02 Nov 2014 09:23:04 +0800 > Julian Elischer wrote: >=20 >> On 10/31/14, 1:09 PM, Tim Kientzle wrote: >>> On Oct 30, 2014, at 2:01 PM, Rick Macklem = wrote: >>>=20 >>>> int64_t i; >>>>=20 >>>> printf("%qd\n", (u_quad_t)i); >>>>=20 >>>> Is there a better way to printf() a int64_t in the kernel? >>>=20 >>> printf(=93%jd\n=94, (intmax_t)i); >=20 > We've always used the PRIxxx types when coding for both 32/64 = platforms, > but it would have been really nice to have a standard way for time_t. > Something like PRItt This is the major reason I prefer the intmax_t cast approach: the PRI* = macros only support a small handful of basic integer types. The intmax_t cast approach only requires you to know whether it's signed = (%jd with intmax_t) or unsigned (%ju with uintmax_t). > On Nov 1, 2014, at 7:14 PM, Rick Macklem wrote: > Oh, and is intmax_t going to be int64_t on all arches? Yes, until we start supporting 128-bit arithmetic. So the only runtime = cost for this approach is that it might have to widen the value. (Given = the cost of printf in general, that's likely not a problem.) Tim From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 18:00:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A31B640B for ; Sun, 2 Nov 2014 18:00:28 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5F537F4D for ; Sun, 2 Nov 2014 18:00:28 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id E37A03BD2B; Sun, 2 Nov 2014 18:00:20 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sA2I0JJP007918; Sun, 2 Nov 2014 18:00:20 GMT (envelope-from phk@phk.freebsd.dk) To: Tim Kientzle Subject: Re: how to kernel printf a int64_t? In-reply-to: <3E8C7E0D-5858-4BFF-8C09-FAA68200B988@kientzle.com> From: "Poul-Henning Kamp" References: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> <97A82163-E78D-457E-B649-B243B41A6C6F@kientzle.com> <54558778.7050500@freebsd.org> <20141102114614.38aa9034@akips.com> <3E8C7E0D-5858-4BFF-8C09-FAA68200B988@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7916.1414951218.1@critter.freebsd.dk> Date: Sun, 02 Nov 2014 18:00:19 +0000 Message-ID: <7917.1414951219@critter.freebsd.dk> X-Mailman-Approved-At: Sun, 02 Nov 2014 18:02:06 +0000 Cc: Freebsd hackers list , Paul Koch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 18:00:28 -0000 -------- >> We've always used the PRIxxx types when coding for both 32/64 platforms, >> but it would have been really nice to have a standard way for time_t. >> Something like PRItt That road leads to madness, because now both the reader and the writer needs to remember what the PRIxx is for inode_t, socklen_t and so on. In no time you've run out of 'xx' and some camelCaseContrarian will start using PRI_inode_t "for readability" and... ARGH! Casting to [u]intmax_t and using %j is horrible, but not nearly as horrible as any other currently available option. The *right* solution, could only exist if ISO-C had consisted of actual C programmers: A varargs definition which transferred both argument and it's type, so that printf wouldn't need any size integers at all, but could tell by itself. The resulting increase in code safety and robustness alone would make this worth the effort to implement. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 18:06:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D43EC55E for ; Sun, 2 Nov 2014 18:06:05 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4465B for ; Sun, 2 Nov 2014 18:06:05 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XkzXP-00011n-VL; Sun, 02 Nov 2014 18:06:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA2I62mo089981; Sun, 2 Nov 2014 11:06:02 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/mBTL9N6GPooLdnOwcY1Pi X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: how to kernel printf a int64_t? From: Ian Lepore To: Poul-Henning Kamp In-Reply-To: <7917.1414951219@critter.freebsd.dk> References: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> <97A82163-E78D-457E-B649-B243B41A6C6F@kientzle.com> <54558778.7050500@freebsd.org> <20141102114614.38aa9034@akips.com> <3E8C7E0D-5858-4BFF-8C09-FAA68200B988@kientzle.com> <7917.1414951219@critter.freebsd.dk> Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Nov 2014 11:06:02 -0700 Message-ID: <1414951562.1200.1.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Paul Koch , Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 18:06:05 -0000 On Sun, 2014-11-02 at 18:00 +0000, Poul-Henning Kamp wrote: > -------- > > >> We've always used the PRIxxx types when coding for both 32/64 platforms, > >> but it would have been really nice to have a standard way for time_t. > >> Something like PRItt > > That road leads to madness, because now both the reader and the writer > needs to remember what the PRIxx is for inode_t, socklen_t and so on. > > In no time you've run out of 'xx' and some camelCaseContrarian will > start using PRI_inode_t "for readability" and... ARGH! > > Casting to [u]intmax_t and using %j is horrible, but not nearly as > horrible as any other currently available option. > > The *right* solution, could only exist if ISO-C had consisted of > actual C programmers: A varargs definition which transferred both > argument and it's type, so that printf wouldn't need any size > integers at all, but could tell by itself. > > The resulting increase in code safety and robustness alone would > make this worth the effort to implement. > VAX/VMS pass-by-descriptor comes back to life in the 21st century! -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 23:02:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7077EADC; Sun, 2 Nov 2014 23:02:35 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 00C2BE0; Sun, 2 Nov 2014 23:02:34 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAIALq3VlSDaFve/2dsb2JhbABcg2JYBIMCyggKhnlUAoEKIwEBAQEBfYQCAQEBAwEBAQEgKyALGxIGAgINGQIpAQkYDgYIBwQBHASIFwkNtGOUGQEBAQcBAQEBAQEBARqBLY8SAQEbATMHgneBVAWLdopzhBKENz2GQoRJhU6ECYQWHy8HgQg5gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,303,1413259200"; d="scan'208";a="165379853" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 02 Nov 2014 18:02:07 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 90E87B406F; Sun, 2 Nov 2014 18:02:07 -0500 (EST) Date: Sun, 2 Nov 2014 18:02:07 -0500 (EST) From: Rick Macklem To: Ian Lepore Message-ID: <1581914338.4217211.1414969327581.JavaMail.root@uoguelph.ca> In-Reply-To: <1414946140.67444.0.camel@revolution.hippie.lan> Subject: Re: how to kernel printf a int64_t? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 23:02:35 -0000 Ian Lepore wrote: > On Mon, 2014-11-03 at 00:04 +0800, Julian Elischer wrote: > > On 11/2/14, 8:48 PM, Rick Macklem wrote: > > > Ian Lepore wrote: > > >> On Sun, 2014-11-02 at 11:20 +0800, Julian Elischer wrote: > > >>> On 11/2/14, 10:14 AM, Rick Macklem wrote: > > >>>> Julian Elischer wrote: > > >>>>> On 10/31/14, 1:09 PM, Tim Kientzle wrote: > > >>>>> > > >>>>> > > >>>>> On Oct 30, 2014, at 2:01 PM, Rick Macklem > > >>>>> > > >>>>> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> I feel kinda dumb asking this, but... > > >>>>> int64_t i; > > >>>>> > > >>>>> printf("%qd\n", (u_quad_t)i); > > >>>>> > > >>>>> works but looks dorky, to put it technically;-). > > >>>>> Is there a better way to printf() a int64_t in the kernel? I > > >>>>> often > > >>>>> use the following to print large integers: > > >>>>> > > >>>>> printf(=E2=80=9C%jd\n=E2=80=9D, (intmax_t)i); the "cannonic= al' way is > > >>>>> to > > >>>>> use > > >>>>> PRIu64 and friends, but some people seem to have a > > >>>>> problem > > >>>>> with > > >>>>> doing that. > > >>>>> > > >>>> Ok, so now I need to ask another dumb question. > > >>>> How do you do this in the kernel? > > >>>> (I can see them defines in , but > > >>>> including > > >>>> that > > >>>> doesn't help, which isn't surprising since PRIu64 is in a > > >>>> string > > >>>> and won't be recognized as a macro.) > > >>> you use it with string concatenation. > > >>> like: > > >>> > > >>> printf (" this is a 64 it unsigned value: %" PRIu64 " and > > >>> I > > >>> just > > >>> printed it\n", thingy64); > > >>> > > >>> After substitution the compiler sees > > >>> " this is a 64 it unsigned value: %" "llu" " and I just > > >>> printed > > >>> it\n" > > >>> which simplifies to: > > >>> " this is a 64 it unsigned value: %llu and I just printed it\n" > > >>> > > >>> due to concatenation. (note I didn't actually look what PRIu64 > > >>> evaluates to) > > >>> > > >>> > > >> Which is exactly the explanation for why "some people seem to > > >> have a > > >> problem with doing that." "Some people" would be "anyone who > > >> thinks > > >> it > > >> should be possible to read code as well as write it." This may > > >> be > > >> more > > >> correct in some pedantic sense, but %j and a cast is more > > >> readable. > > >> > > > Yes, thanks. I'll admit to thinking exactly the same thing. > > > I guess I'll use %j. > > then your code could be wrong in some cases.. > >=20 >=20 > The recommendation was "%j and a cast" not just %j. The cast will > ensure that the size of the argument matches the size of the format. >=20 Yes, I understood that (just didn't state it in the above). Thanks, rick > > PRIu64 specifies that the value will always be 64 bits (unsigned) > > on > > every architecture. > > If that's NOT true then yes, use a type (e.g. %d) that varies here > > and > > there. > > If your value will ALWAYS be 64 but then PRIu64 describes what it > > is > > much better than > > %j, because you need to know what %j expects on every architecture > > your > > code may ever run on. > >=20 >=20 > It is well-known what the %j size modifier expects on every > architecture: the size of a value of type [u]intmax_t, which is what > the corresponding argument cast provides. It is a given that > [u]intmax_t is able to represent all other integer types of the > corresponding signedness. >=20 > > In my own opinion, PRIu64 is much more readable than %j because the > > size > > and expected signed/unsigned characterisitics are right there, > > where > > %randomletter is exactly that.. completely random, requiring that > > the > > reader go > > consult a man page first before reading code for any given > > architecture. > >=20 >=20 > I'm willing to be proven wrong that %j and the corresponding > [u]intmax_t > cast will provide the wrong result in some case. But the proof has > to > be in the form of something other than "I disagree with you on which > one > is more readable". You seem to be conflating correctness of > operation > with stylistic opinion in your reply (sorry if that's not your intent > and the conflation is only in my head). >=20 > -- Ian >=20 >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" >=20 From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 03:41:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF980A26 for ; Mon, 3 Nov 2014 03:41:03 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33E0DD16 for ; Mon, 3 Nov 2014 03:41:03 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id gq15so8945806lab.1 for ; Sun, 02 Nov 2014 19:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:reply-to:to:subject:date:mime-version:content-type :thread-index:content-language; bh=S8vtFJ4Xy7PIIqLBOkAQ5BD0MrYRewBxVAIRJ9rqMeM=; b=m9KLDteSYcmAKZBHyHM3dL89JzqtjnzUIkdJl8GZGS+v3iJk08j/8jYMF+0smLmEFu tn4lLmh082qQky3JeH2vvKvr2s0IuPtyQSzarLdHVoW6p7OuFb/RWJVUdZxP4UNxcgiB hQsOag41J4qFtBlatbKG3fCOk5v7TdeHqAk9XrExWGxQmIU5IPjbZWFPV+XXnm1E1Q5L BfNMAEE+XSDwg7BKkqOs3ZP86MMgSrrb+2L6ObzgRYGvdl4eDKLYKZx7f48+0s7C9YGI /55Dlbo+aVo2nkf9tU/j2V2WxI8erGFkZOUsu5Mu1mypBvYorCOEKfs8EllgHNzgWSX8 zzuw== X-Received: by 10.112.139.165 with SMTP id qz5mr9414241lbb.96.1414986061144; Sun, 02 Nov 2014 19:41:01 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:2497:9687:421b:c20e]) by mx.google.com with ESMTPSA id mn4sm7422492lbb.4.2014.11.02.19.40.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Nov 2014 19:41:00 -0800 (PST) Message-ID: <5456f94c.247d700a.771d.ffff869e@mx.google.com> X-Google-Original-Message-ID: <007101cff717$fbd14c60$f373e520$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: Subject: pagedaemon + rtorrent = fail Date: Mon, 3 Nov 2014 06:40:57 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0072_01CFF731.211E8460" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/3F/pkV86unfLIRj2GXhwrU20Enw== Content-Language: ru X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 03:41:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0072_01CFF731.211E8460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Problem described here: https://forums.freebsd.org/threads/heavy-use-rtorrent-ufs-issues.14503/ http://www.bsdportal.ru/viewtopic.php?f=9&t=25194 http://forum.lissyara.su/viewtopic.php?f=53&t=39944 Swap is off: vm.swap_enabled=0 and no swap devices. I wrote a small program to demonstrate the problem. The program creates a file size of 2*"RAM size", map() block size specified, records in each page by byte, unmap(), map() next block... Once a file is written to more "RAM size" OOM kills the program and random demons. In the TOP program does not consume more than the write_block size (32 mb) for recording. Check the parameters before the test run. ------=_NextPart_000_0072_01CFF731.211E8460 Content-Type: text/plain; name="testvm.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="testvm.c" =0A= /* rtorrent + FreeBSD pagedaemon prombel simulator=0A= * 2014 Rozhuk Ivan =0A= *=0A= * compile-command: "clang -Wall -O2 -o testvm testvm.c"=0A= */=0A= =0A= =0A= #include =0A= #include =0A= #include // chmod, fchmod, umask=0A= #include /* readv, preadv, writev, pwritev */=0A= #include /* mmap, munmap */=0A= =0A= #include =0A= #include /* open, fcntl */=0A= #include /* snprintf, fprintf */=0A= #include /* bcopy, bzero, memcpy, memmove, memset, strnlen, = strerror... */=0A= #include /* close, write, sysconf */=0A= #include /* malloc, exit */=0A= =0A= #define LOG_ERR(error, descr) \=0A= fprintf(stdout, "fn: %s, line: %i, error: %i - %s, %s\n", \=0A= __FUNCTION__, __LINE__, error, strerror(error), descr);=0A= =0A= int=0A= main(int argc, char *argv[]) {=0A= int error =3D 0, fd;=0A= const char *file_name =3D (const char *)"/testvn.tmp";=0A= off_t mb =3D (1024 * 1024); /* 1 megabyte. */=0A= off_t file_size =3D (10 * 1024 * mb); /* Set to x2 RAM size. */=0A= off_t write_size =3D (32 * mb); /* Write block size. */=0A= off_t i, j, page_size;=0A= uint8_t *mem;=0A= =0A= fd =3D open(file_name, (O_RDWR | O_CREAT), 0600);=0A= if (-1 =3D=3D fd) {=0A= error =3D errno;=0A= LOG_ERR(error, "open()");=0A= goto err_out;=0A= }=0A= if (0 !=3D flock(fd, LOCK_EX)) {=0A= error =3D errno;=0A= LOG_ERR(error, "flock()");=0A= goto err_out;=0A= }=0A= if (0 !=3D ftruncate(fd, file_size)) {=0A= error =3D errno;=0A= LOG_ERR(error, "ftruncate()");=0A= goto err_out;=0A= }=0A= =0A= page_size =3D sysconf(_SC_PAGE_SIZE);=0A= for (i =3D 0; i < (file_size / write_size); i ++) {=0A= mem =3D mmap(NULL, write_size, (PROT_READ | PROT_WRITE),=0A= (MAP_SHARED | MAP_NOCORE), fd, (i * write_size));=0A= if (MAP_FAILED =3D=3D mem) {=0A= error =3D errno;=0A= LOG_ERR(error, "mmap()");=0A= goto err_out;=0A= }=0A= for (j =3D 0; j < (write_size / page_size); j ++) {=0A= mem[(j * page_size)] =3D 1;=0A= }=0A= munmap(mem, file_size);=0A= }=0A= =0A= err_out:=0A= close(fd);=0A= //unlink(file_name); /* Delete file to free all mem. */=0A= =0A= return (error);=0A= }=0A= ------=_NextPart_000_0072_01CFF731.211E8460-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 04:02:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7547D1EB; Mon, 3 Nov 2014 04:02:48 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 30737F78; Mon, 3 Nov 2014 04:02:46 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygDXuRZV_lZUxd3FAA--.18577S2; Mon, 03 Nov 2014 12:02:39 +0800 (CST) From: Tiwei Bie To: mjg@freebsd.org Subject: [PATCH] Finish the task 'sysctl reporting current working directory' Date: Mon, 3 Nov 2014 12:02:05 +0800 Message-Id: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygDXuRZV_lZUxd3FAA--.18577S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAFy3CF47GF15trWxCr45Wrg_yoWrZFykpa nxArnrtw47GF18Kr4kKr45u3WSkw18XF48WFWkuw43ZFsYqr10gr1Iqr90vF1S93y5W39I vF45tFyrGw10yFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1Y6r17McIj6I8E87Iv67AKxVW8JVWxJw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r45MxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07b7a9-UUUUU= X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUQAVQhl8xmIgAKs1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 04:02:48 -0000 Hi, Mateusz! I have finished the task: sysctl reporting current working directory [1]. The patch for tmux is against tmux-1.9a [2]. #1. Patch for FreeBSD: diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 11ab4ba..4652cb9 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -3409,6 +3409,72 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_FILEDESC, filedesc, CTLFLAG_RD|CTLFLAG_MPSAFE, sysctl_kern_proc_filedesc, "Process filedesc entries"); +/* + * Store a process current working directory information to sbuf. + * + * Takes a locked proc as argument, and returns with the proc unlocked. + */ +int +kern_proc_cwd_out(struct proc *p, struct sbuf *sb, ssize_t maxlen) +{ + struct filedesc *fdp; + struct export_fd_buf *efbuf; + int error = 0; + + PROC_LOCK_ASSERT(p, MA_OWNED); + + fdp = fdhold(p); + PROC_UNLOCK(p); + + if (fdp == NULL) + return (error); + + efbuf = malloc(sizeof(*efbuf), M_TEMP, M_WAITOK); + efbuf->fdp = fdp; + efbuf->sb = sb; + efbuf->remainder = maxlen; + + FILEDESC_SLOCK(fdp); + /* working directory */ + if (fdp->fd_cdir != NULL) { + vref(fdp->fd_cdir); + export_vnode_to_sb(fdp->fd_cdir, KF_FD_TYPE_CWD, FREAD, efbuf); + } + FILEDESC_SUNLOCK(fdp); + fddrop(fdp); + free(efbuf, M_TEMP); + return (error); +} + +/* + * Get per-process current working directory. + */ +static int +sysctl_kern_proc_cwd(SYSCTL_HANDLER_ARGS) +{ + struct sbuf sb; + struct proc *p; + ssize_t maxlen; + int error, error2, *name; + + name = (int *)arg1; + + sbuf_new_for_sysctl(&sb, NULL, sizeof(struct kinfo_file), req); + error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); + if (error != 0) { + sbuf_delete(&sb); + return (error); + } + maxlen = req->oldptr != NULL ? req->oldlen : -1; + error = kern_proc_cwd_out(p, &sb, maxlen); + error2 = sbuf_finish(&sb); + sbuf_delete(&sb); + return (error != 0 ? error : error2); +} + +static SYSCTL_NODE(_kern_proc, KERN_PROC_CWD, cwd, CTLFLAG_RD|CTLFLAG_MPSAFE, + sysctl_kern_proc_cwd, "Process current working directory"); + #ifdef DDB /* * For the purposes of debugging, generate a human-readable string for the diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h index d782375..f3173c2 100644 --- a/sys/sys/sysctl.h +++ b/sys/sys/sysctl.h @@ -657,6 +657,7 @@ TAILQ_HEAD(sysctl_ctx_list, sysctl_ctx_entry); #define KERN_PROC_UMASK 39 /* process umask */ #define KERN_PROC_OSREL 40 /* osreldate for process binary */ #define KERN_PROC_SIGTRAMP 41 /* signal trampoline location */ +#define KERN_PROC_CWD 42 /* process current working directory */ /* * KERN_IPC identifiers diff --git a/sys/sys/user.h b/sys/sys/user.h index f0d059e..c3b3bc5 100644 --- a/sys/sys/user.h +++ b/sys/sys/user.h @@ -530,6 +530,7 @@ struct sbuf; */ int kern_proc_filedesc_out(struct proc *p, struct sbuf *sb, ssize_t maxlen); +int kern_proc_cwd_out(struct proc *p, struct sbuf *sb, ssize_t maxlen); int kern_proc_out(struct proc *p, struct sbuf *sb, int flags); int kern_proc_vmmap_out(struct proc *p, struct sbuf *sb); -- 2.1.0 #2. Patch for tmux: diff --git a/osdep-freebsd.c b/osdep-freebsd.c index d596eab..f2443b7 100644 --- a/osdep-freebsd.c +++ b/osdep-freebsd.c @@ -136,26 +136,39 @@ char * osdep_get_cwd(int fd) { static char wd[PATH_MAX]; - struct kinfo_file *info = NULL; pid_t pgrp; - int nrecords, i; + int mib[4]; + size_t len; + struct kinfo_file *info; + char *buf; + int error; if ((pgrp = tcgetpgrp(fd)) == -1) return (NULL); - if ((info = kinfo_getfile(pgrp, &nrecords)) == NULL) + mib[0] = CTL_KERN; + mib[1] = KERN_PROC; + mib[2] = KERN_PROC_CWD; + mib[3] = pgrp; + + error = sysctl(mib, 4, NULL, &len, NULL, 0); + if (error) return (NULL); - for (i = 0; i < nrecords; i++) { - if (info[i].kf_fd == KF_FD_TYPE_CWD) { - strlcpy(wd, info[i].kf_path, sizeof wd); - free(info); - return (wd); - } + buf = malloc(len); + if (buf == NULL) + return (NULL); + error = sysctl(mib, 4, buf, &len, NULL, 0); + if (error) { + free(buf); + return (NULL); } - free(info); - return (NULL); + info = (struct kinfo_file *)buf; + strlcpy(wd, info->kf_path, sizeof wd); + + free(buf); + return (wd); } struct event_base * -- 2.1.0 [1] https://wiki.freebsd.org/JuniorJobs#sysctl_reporting_current_working_directory [2] http://cznic.dl.sourceforge.net/project/tmux/tmux/tmux-1.9/tmux-1.9a.tar.gz Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 05:19:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01141CED; Mon, 3 Nov 2014 05:19:13 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 680E6824; Mon, 3 Nov 2014 05:19:13 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id x12so9743736wgg.31 for ; Sun, 02 Nov 2014 21:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=z/BBSbW6Vhr2AcVhWL12cnEFAZlDejMT8I8TSBCcDew=; b=vbdjb7iFEe9lOzDmEhtQfo6+NB17Aooorp587Bp1g8HL+P9YfJXrqMMHNzQXc/p8JG Cv2UYe+Uy+JcEFf4LYw8B6Jj0qQjy9++NpW5oWyuWyzshKgCODWLGD0jZopVPKYrW+mQ PPaFYGKSPezahFBQG1B91aUXSGue6Wmkd/3jeB+ht+LEtXIaPmo5IYaVU03az7hr9ils 5Ix06JvccvTna78sE05RqRUMnGoyrE1Dx5BBsz2DEVjHzFkapgHhg1HeaAEjafmUpsdU wuTFsVx8ct5xAv7N84JTWKmxF8BAejiJGdfceodE1thA/CWUM80q6ZLVOagkb6+QWO/V eAKg== X-Received: by 10.180.14.226 with SMTP id s2mr13374095wic.61.1414991951384; Sun, 02 Nov 2014 21:19:11 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fa7sm20853086wjd.27.2014.11.02.21.19.10 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 02 Nov 2014 21:19:10 -0800 (PST) Date: Mon, 3 Nov 2014 06:19:08 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103051908.GC29497@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , mjg@freebsd.org, freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, mjg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 05:19:14 -0000 On Mon, Nov 03, 2014 at 12:02:05PM +0800, Tiwei Bie wrote: > Hi, Mateusz! > > I have finished the task: sysctl reporting current working directory [1]. > > The patch for tmux is against tmux-1.9a [2]. > > #1. Patch for FreeBSD: > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 11ab4ba..4652cb9 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -3409,6 +3409,72 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_FILEDESC, filedesc, > CTLFLAG_RD|CTLFLAG_MPSAFE, sysctl_kern_proc_filedesc, > "Process filedesc entries"); > > +/* > + * Store a process current working directory information to sbuf. > + * > + * Takes a locked proc as argument, and returns with the proc unlocked. > + */ > +int > +kern_proc_cwd_out(struct proc *p, struct sbuf *sb, ssize_t maxlen) > +{ > + struct filedesc *fdp; > + struct export_fd_buf *efbuf; > + int error = 0; > + > + PROC_LOCK_ASSERT(p, MA_OWNED); > + > + fdp = fdhold(p); > + PROC_UNLOCK(p); > + > + if (fdp == NULL) > + return (error); > + This returns 0 which does not seem to be the righit choice. EINVAL seems more suitable. > + efbuf = malloc(sizeof(*efbuf), M_TEMP, M_WAITOK); > + efbuf->fdp = fdp; > + efbuf->sb = sb; > + efbuf->remainder = maxlen; > + > + FILEDESC_SLOCK(fdp); > + /* working directory */ Unnecessary comment. > + if (fdp->fd_cdir != NULL) { > + vref(fdp->fd_cdir); > + export_vnode_to_sb(fdp->fd_cdir, KF_FD_TYPE_CWD, FREAD, efbuf); Missing error checking. > + } > + FILEDESC_SUNLOCK(fdp); > + fddrop(fdp); > + free(efbuf, M_TEMP); > + return (error); So as it is the function always returns 0. Other than that kernel part seems fine. > +} > + > +/* > + * Get per-process current working directory. > + */ > +static int > +sysctl_kern_proc_cwd(SYSCTL_HANDLER_ARGS) > +{ > + struct sbuf sb; > + struct proc *p; > + ssize_t maxlen; > + int error, error2, *name; > + > + name = (int *)arg1; > + > + sbuf_new_for_sysctl(&sb, NULL, sizeof(struct kinfo_file), req); > + error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > + if (error != 0) { > + sbuf_delete(&sb); > + return (error); > + } > + maxlen = req->oldptr != NULL ? req->oldlen : -1; > + error = kern_proc_cwd_out(p, &sb, maxlen); > + error2 = sbuf_finish(&sb); > + sbuf_delete(&sb); > + return (error != 0 ? error : error2); > +} > + > +static SYSCTL_NODE(_kern_proc, KERN_PROC_CWD, cwd, CTLFLAG_RD|CTLFLAG_MPSAFE, > + sysctl_kern_proc_cwd, "Process current working directory"); > + > #ifdef DDB > /* > * For the purposes of debugging, generate a human-readable string for the > diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h > index d782375..f3173c2 100644 > --- a/sys/sys/sysctl.h > +++ b/sys/sys/sysctl.h > @@ -657,6 +657,7 @@ TAILQ_HEAD(sysctl_ctx_list, sysctl_ctx_entry); > #define KERN_PROC_UMASK 39 /* process umask */ > #define KERN_PROC_OSREL 40 /* osreldate for process binary */ > #define KERN_PROC_SIGTRAMP 41 /* signal trampoline location */ > +#define KERN_PROC_CWD 42 /* process current working directory */ > > /* > * KERN_IPC identifiers > diff --git a/sys/sys/user.h b/sys/sys/user.h > index f0d059e..c3b3bc5 100644 > --- a/sys/sys/user.h > +++ b/sys/sys/user.h > @@ -530,6 +530,7 @@ struct sbuf; > */ > > int kern_proc_filedesc_out(struct proc *p, struct sbuf *sb, ssize_t maxlen); > +int kern_proc_cwd_out(struct proc *p, struct sbuf *sb, ssize_t maxlen); > int kern_proc_out(struct proc *p, struct sbuf *sb, int flags); > int kern_proc_vmmap_out(struct proc *p, struct sbuf *sb); > > -- > 2.1.0 > > > #2. Patch for tmux: > > diff --git a/osdep-freebsd.c b/osdep-freebsd.c > index d596eab..f2443b7 100644 > --- a/osdep-freebsd.c > +++ b/osdep-freebsd.c > @@ -136,26 +136,39 @@ char * > osdep_get_cwd(int fd) > { > static char wd[PATH_MAX]; > - struct kinfo_file *info = NULL; > pid_t pgrp; > - int nrecords, i; > + int mib[4]; > + size_t len; > + struct kinfo_file *info; > + char *buf; > + int error; > > if ((pgrp = tcgetpgrp(fd)) == -1) > return (NULL); > > - if ((info = kinfo_getfile(pgrp, &nrecords)) == NULL) > + mib[0] = CTL_KERN; > + mib[1] = KERN_PROC; > + mib[2] = KERN_PROC_CWD; > + mib[3] = pgrp; > + > + error = sysctl(mib, 4, NULL, &len, NULL, 0); > + if (error) > return (NULL); > > - for (i = 0; i < nrecords; i++) { > - if (info[i].kf_fd == KF_FD_TYPE_CWD) { > - strlcpy(wd, info[i].kf_path, sizeof wd); > - free(info); > - return (wd); > - } > + buf = malloc(len); > + if (buf == NULL) > + return (NULL); > + error = sysctl(mib, 4, buf, &len, NULL, 0); > + if (error) { > + free(buf); > + return (NULL); > } > > - free(info); > - return (NULL); > + info = (struct kinfo_file *)buf; > + strlcpy(wd, info->kf_path, sizeof wd); > + > + free(buf); > + return (wd); This cannot be right. tmux has to remain compilable on versions without this new sysctl. You can ifdef the code based on KERN_PROC_CWD. > } > > struct event_base * > -- > 2.1.0 > > [1] https://wiki.freebsd.org/JuniorJobs#sysctl_reporting_current_working_directory > [2] http://cznic.dl.sourceforge.net/project/tmux/tmux/tmux-1.9/tmux-1.9a.tar.gz > > Tiwei Bie > -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 06:42:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAD2014E for ; Mon, 3 Nov 2014 06:42:07 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 8ECD0F4B for ; Mon, 3 Nov 2014 06:42:05 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygBnbPSNI1dUuZTGAA--.1780S2; Mon, 03 Nov 2014 14:41:23 +0800 (CST) Date: Mon, 3 Nov 2014 14:40:52 +0800 From: Tiwei Bie To: Mateusz Guzik Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103064052.GA1739@freebsd> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141103051908.GC29497@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygBnbPSNI1dUuZTGAA--.1780S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Zry3XFW8tr4rZFW5Ar17Awb_yoWDWrWfpa n8AFsrtF47GF1UKr4vqr4ru3WSkw18XF1xWay8Ww43AFsYvr18Wr1Iqr909F1fu3y5u34S vF45KFn3Gw10yFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1Y6r17McIj6I8E87Iv67AKxVW8JVWxJw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc2xSY4AK67AK6r47MxAIw28IcxkI 7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6x AIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv 6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07b7XocUUUUU= X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQURAVQhl8yZCAAEsv Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 06:42:07 -0000 On Mon, Nov 03, 2014 at 06:19:08AM +0100, Mateusz Guzik wrote: > On Mon, Nov 03, 2014 at 12:02:05PM +0800, Tiwei Bie wrote: > > Hi, Mateusz! > > > > I have finished the task: sysctl reporting current working directory [1]. > > > > The patch for tmux is against tmux-1.9a [2]. > > > > #1. Patch for FreeBSD: > > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > > index 11ab4ba..4652cb9 100644 > > --- a/sys/kern/kern_descrip.c > > +++ b/sys/kern/kern_descrip.c > > @@ -3409,6 +3409,72 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_FILEDESC, filedesc, > > CTLFLAG_RD|CTLFLAG_MPSAFE, sysctl_kern_proc_filedesc, > > "Process filedesc entries"); > > > > +/* > > + * Store a process current working directory information to sbuf. > > + * > > + * Takes a locked proc as argument, and returns with the proc unlocked. > > + */ > > +int > > +kern_proc_cwd_out(struct proc *p, struct sbuf *sb, ssize_t maxlen) > > +{ > > + struct filedesc *fdp; > > + struct export_fd_buf *efbuf; > > + int error = 0; > > + > > + PROC_LOCK_ASSERT(p, MA_OWNED); > > + > > + fdp = fdhold(p); > > + PROC_UNLOCK(p); > > + > > + if (fdp == NULL) > > + return (error); > > + > > This returns 0 which does not seem to be the righit choice. > > EINVAL seems more suitable. > I got it, this is a different situation with kern_proc_filedesc_out(), In kern_proc_filedesc_out(), data about tracevp, textvp and cttyvp has already been got. So it just returns 0. I mixed them. Thank you. int kern_proc_filedesc_out(struct proc *p, struct sbuf *sb, ssize_t maxlen) { ...... error = 0; if (fdp == NULL) goto fail; ...... fail: free(efbuf, M_TEMP); return (error); } > > + efbuf = malloc(sizeof(*efbuf), M_TEMP, M_WAITOK); > > + efbuf->fdp = fdp; > > + efbuf->sb = sb; > > + efbuf->remainder = maxlen; > > + > > + FILEDESC_SLOCK(fdp); > > + /* working directory */ > > Unnecessary comment. > > > + if (fdp->fd_cdir != NULL) { > > + vref(fdp->fd_cdir); > > + export_vnode_to_sb(fdp->fd_cdir, KF_FD_TYPE_CWD, FREAD, efbuf); > > Missing error checking. > I have considered checking its return value like this: if (fdp->fd_cdir != NULL) { vref(fdp->fd_cdir); error = export_vnode_to_sb(fdp->fd_cdir, KF_FD_TYPE_CWD, FREAD, efbuf); } But the code in kern_proc_filedesc_out() doesn't do this. So, I don't know whether I should return this error code. But now, as we have only to deal with current working directory, and no other data will be exported, I think we could return with this error code. > > + } > > + FILEDESC_SUNLOCK(fdp); > > + fddrop(fdp); > > + free(efbuf, M_TEMP); > > + return (error); > > > So as it is the function always returns 0. > > Other than that kernel part seems fine. > > > +} > > + > > +/* > > + * Get per-process current working directory. > > + */ > > +static int > > +sysctl_kern_proc_cwd(SYSCTL_HANDLER_ARGS) > > +{ > > + struct sbuf sb; > > + struct proc *p; > > + ssize_t maxlen; > > + int error, error2, *name; > > + > > + name = (int *)arg1; > > + > > + sbuf_new_for_sysctl(&sb, NULL, sizeof(struct kinfo_file), req); > > + error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > > + if (error != 0) { > > + sbuf_delete(&sb); > > + return (error); > > + } > > + maxlen = req->oldptr != NULL ? req->oldlen : -1; > > + error = kern_proc_cwd_out(p, &sb, maxlen); > > + error2 = sbuf_finish(&sb); > > + sbuf_delete(&sb); > > + return (error != 0 ? error : error2); > > +} > > + > > +static SYSCTL_NODE(_kern_proc, KERN_PROC_CWD, cwd, CTLFLAG_RD|CTLFLAG_MPSAFE, > > + sysctl_kern_proc_cwd, "Process current working directory"); > > + > > #ifdef DDB > > /* > > * For the purposes of debugging, generate a human-readable string for the > > diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h > > index d782375..f3173c2 100644 > > --- a/sys/sys/sysctl.h > > +++ b/sys/sys/sysctl.h > > @@ -657,6 +657,7 @@ TAILQ_HEAD(sysctl_ctx_list, sysctl_ctx_entry); > > #define KERN_PROC_UMASK 39 /* process umask */ > > #define KERN_PROC_OSREL 40 /* osreldate for process binary */ > > #define KERN_PROC_SIGTRAMP 41 /* signal trampoline location */ > > +#define KERN_PROC_CWD 42 /* process current working directory */ > > > > /* > > * KERN_IPC identifiers > > diff --git a/sys/sys/user.h b/sys/sys/user.h > > index f0d059e..c3b3bc5 100644 > > --- a/sys/sys/user.h > > +++ b/sys/sys/user.h > > @@ -530,6 +530,7 @@ struct sbuf; > > */ > > > > int kern_proc_filedesc_out(struct proc *p, struct sbuf *sb, ssize_t maxlen); > > +int kern_proc_cwd_out(struct proc *p, struct sbuf *sb, ssize_t maxlen); > > int kern_proc_out(struct proc *p, struct sbuf *sb, int flags); > > int kern_proc_vmmap_out(struct proc *p, struct sbuf *sb); > > > > -- > > 2.1.0 > > > > > > #2. Patch for tmux: > > > > diff --git a/osdep-freebsd.c b/osdep-freebsd.c > > index d596eab..f2443b7 100644 > > --- a/osdep-freebsd.c > > +++ b/osdep-freebsd.c > > @@ -136,26 +136,39 @@ char * > > osdep_get_cwd(int fd) > > { > > static char wd[PATH_MAX]; > > - struct kinfo_file *info = NULL; > > pid_t pgrp; > > - int nrecords, i; > > + int mib[4]; > > + size_t len; > > + struct kinfo_file *info; > > + char *buf; > > + int error; > > > > if ((pgrp = tcgetpgrp(fd)) == -1) > > return (NULL); > > > > - if ((info = kinfo_getfile(pgrp, &nrecords)) == NULL) > > + mib[0] = CTL_KERN; > > + mib[1] = KERN_PROC; > > + mib[2] = KERN_PROC_CWD; > > + mib[3] = pgrp; > > + > > + error = sysctl(mib, 4, NULL, &len, NULL, 0); > > + if (error) > > return (NULL); > > > > - for (i = 0; i < nrecords; i++) { > > - if (info[i].kf_fd == KF_FD_TYPE_CWD) { > > - strlcpy(wd, info[i].kf_path, sizeof wd); > > - free(info); > > - return (wd); > > - } > > + buf = malloc(len); > > + if (buf == NULL) > > + return (NULL); > > + error = sysctl(mib, 4, buf, &len, NULL, 0); > > + if (error) { > > + free(buf); > > + return (NULL); > > } > > > > - free(info); > > - return (NULL); > > + info = (struct kinfo_file *)buf; > > + strlcpy(wd, info->kf_path, sizeof wd); > > + > > + free(buf); > > + return (wd); > > This cannot be right. tmux has to remain compilable on versions without > this new sysctl. > > You can ifdef the code based on KERN_PROC_CWD. > I got it, thank you! Following are my new patches: #1. Patch for FreeBSD: diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 2d1a5af..949c2d3 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -3410,6 +3410,75 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_FILEDESC, filedesc, CTLFLAG_RD|CTLFLAG_MPSAFE, sysctl_kern_proc_filedesc, "Process filedesc entries"); +/* + * Store a process current working directory information to sbuf. + * + * Takes a locked proc as argument, and returns with the proc unlocked. + */ +int +kern_proc_cwd_out(struct proc *p, struct sbuf *sb, ssize_t maxlen) +{ + struct filedesc *fdp; + struct export_fd_buf *efbuf; + int error; + + PROC_LOCK_ASSERT(p, MA_OWNED); + + fdp = fdhold(p); + PROC_UNLOCK(p); + + if (fdp == NULL) + return (EINVAL); + + efbuf = malloc(sizeof(*efbuf), M_TEMP, M_WAITOK); + efbuf->fdp = fdp; + efbuf->sb = sb; + efbuf->remainder = maxlen; + + FILEDESC_SLOCK(fdp); + if (fdp->fd_cdir == NULL) + error = EINVAL; + else { + vref(fdp->fd_cdir); + error = export_vnode_to_sb(fdp->fd_cdir, KF_FD_TYPE_CWD, + FREAD, efbuf); + } + + FILEDESC_SUNLOCK(fdp); + fddrop(fdp); + free(efbuf, M_TEMP); + return (error); +} + +/* + * Get per-process current working directory. + */ +static int +sysctl_kern_proc_cwd(SYSCTL_HANDLER_ARGS) +{ + struct sbuf sb; + struct proc *p; + ssize_t maxlen; + int error, error2, *name; + + name = (int *)arg1; + + sbuf_new_for_sysctl(&sb, NULL, sizeof(struct kinfo_file), req); + error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); + if (error != 0) { + sbuf_delete(&sb); + return (error); + } + maxlen = req->oldptr != NULL ? req->oldlen : -1; + error = kern_proc_cwd_out(p, &sb, maxlen); + error2 = sbuf_finish(&sb); + sbuf_delete(&sb); + return (error != 0 ? error : error2); +} + +static SYSCTL_NODE(_kern_proc, KERN_PROC_CWD, cwd, CTLFLAG_RD|CTLFLAG_MPSAFE, + sysctl_kern_proc_cwd, "Process current working directory"); + #ifdef DDB /* * For the purposes of debugging, generate a human-readable string for the diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h index d782375..f3173c2 100644 --- a/sys/sys/sysctl.h +++ b/sys/sys/sysctl.h @@ -657,6 +657,7 @@ TAILQ_HEAD(sysctl_ctx_list, sysctl_ctx_entry); #define KERN_PROC_UMASK 39 /* process umask */ #define KERN_PROC_OSREL 40 /* osreldate for process binary */ #define KERN_PROC_SIGTRAMP 41 /* signal trampoline location */ +#define KERN_PROC_CWD 42 /* process current working directory */ /* * KERN_IPC identifiers diff --git a/sys/sys/user.h b/sys/sys/user.h index f0d059e..c3b3bc5 100644 --- a/sys/sys/user.h +++ b/sys/sys/user.h @@ -530,6 +530,7 @@ struct sbuf; */ int kern_proc_filedesc_out(struct proc *p, struct sbuf *sb, ssize_t maxlen); +int kern_proc_cwd_out(struct proc *p, struct sbuf *sb, ssize_t maxlen); int kern_proc_out(struct proc *p, struct sbuf *sb, int flags); int kern_proc_vmmap_out(struct proc *p, struct sbuf *sb); -- 2.1.0 #2. Patch for tmux: diff --git a/osdep-freebsd.c b/osdep-freebsd.c index d596eab..4178f01 100644 --- a/osdep-freebsd.c +++ b/osdep-freebsd.c @@ -132,6 +132,46 @@ error: return (NULL); } +#ifdef KERN_PROC_CWD +char * +osdep_get_cwd(int fd) +{ + static char wd[PATH_MAX]; + pid_t pgrp; + int mib[4]; + size_t len; + struct kinfo_file *info; + char *buf; + int error; + + if ((pgrp = tcgetpgrp(fd)) == -1) + return (NULL); + + mib[0] = CTL_KERN; + mib[1] = KERN_PROC; + mib[2] = KERN_PROC_CWD; + mib[3] = pgrp; + + error = sysctl(mib, 4, NULL, &len, NULL, 0); + if (error) + return (NULL); + + buf = malloc(len); + if (buf == NULL) + return (NULL); + error = sysctl(mib, 4, buf, &len, NULL, 0); + if (error) { + free(buf); + return (NULL); + } + + info = (struct kinfo_file *)buf; + strlcpy(wd, info->kf_path, sizeof wd); + + free(buf); + return (wd); +} +#else /* !KERN_PROC_CWD */ char * osdep_get_cwd(int fd) { @@ -157,6 +197,7 @@ osdep_get_cwd(int fd) free(info); return (NULL); } +#endif /* KERN_PROC_CWD */ struct event_base * osdep_event_init(void) -- 2.1.0 Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 08:05:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F18A823 for ; Mon, 3 Nov 2014 08:05:32 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C842F9BB for ; Mon, 3 Nov 2014 08:05:31 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id h11so5673607wiw.9 for ; Mon, 03 Nov 2014 00:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=XiffwQT7+gXU8kgHFniv/ubpUTSl//Mu9czkW5OSfcE=; b=rkuLWfsHfHLxGNh5UP5fkh3i5XGtJCfsyl3OQiL0/V94INdxD+chJP9Q1AVqbR2hfC Hj/0WOzBHWvphcEIiIbm33hqHMuNKkrrnaCIqTlVC8fOF3JaQ2qbdAsGaVjOpbkAEIbm cLaGwhHk1MBalsgCFL42u5YTpWiIskTZptYLbemNLt2RnzhqW11qQrSv6ML5m75gRrzy jkof45JyxqMzVp58nBtKrxcxTdIAdP2WTtejnzF/X/iABGulqv6bH6Xch7ktanu90R1E qtA+UzV1KDjthlRcAfmsnIPJMROF4X+WA9SE1RdSiRDu9+Du3uDKQnW1V1tfCc7kw7yh 8a5w== X-Received: by 10.194.92.195 with SMTP id co3mr21184344wjb.29.1415001929919; Mon, 03 Nov 2014 00:05:29 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id l4sm17861855wjx.14.2014.11.03.00.05.28 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 03 Nov 2014 00:05:29 -0800 (PST) Date: Mon, 3 Nov 2014 09:05:26 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103080526.GE29497@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141103064052.GA1739@freebsd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 08:05:32 -0000 On Mon, Nov 03, 2014 at 02:40:52PM +0800, Tiwei Bie wrote: Kernel patch is ok. > > #2. Patch for tmux: > > diff --git a/osdep-freebsd.c b/osdep-freebsd.c > index d596eab..4178f01 100644 > --- a/osdep-freebsd.c > +++ b/osdep-freebsd.c > @@ -132,6 +132,46 @@ error: > return (NULL); > } > > +#ifdef KERN_PROC_CWD > +char * > +osdep_get_cwd(int fd) > +{ > + static char wd[PATH_MAX]; > + pid_t pgrp; > + int mib[4]; > + size_t len; > + struct kinfo_file *info; > + char *buf; > + int error; > + > + if ((pgrp = tcgetpgrp(fd)) == -1) > + return (NULL); > + > + mib[0] = CTL_KERN; > + mib[1] = KERN_PROC; > + mib[2] = KERN_PROC_CWD; Take a look at osdep-openbsd. This should be done along with declaration. > + mib[3] = pgrp; > + > + error = sysctl(mib, 4, NULL, &len, NULL, 0); > + if (error) > + return (NULL); > + > + buf = malloc(len); > + if (buf == NULL) > + return (NULL); > + error = sysctl(mib, 4, buf, &len, NULL, 0); > + if (error) { > + free(buf); > + return (NULL); > + } > + > + info = (struct kinfo_file *)buf; > + strlcpy(wd, info->kf_path, sizeof wd); > + > + free(buf); Why? Just have static kinfo_file. There is no need to allocate or copy anything, nor to query for size. > + return (wd); > +} > +#else /* !KERN_PROC_CWD */ > char * > osdep_get_cwd(int fd) > { > @@ -157,6 +197,7 @@ osdep_get_cwd(int fd) > free(info); > return (NULL); > } > +#endif /* KERN_PROC_CWD */ > > struct event_base * > osdep_event_init(void) > -- > 2.1.0 > > Tiwei Bie > -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 08:14:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0A679DC for ; Mon, 3 Nov 2014 08:14:26 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 93294A99 for ; Mon, 3 Nov 2014 08:14:26 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA38ED22021894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 3 Nov 2014 00:14:17 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5457394E.4050905@freebsd.org> Date: Mon, 03 Nov 2014 16:14:06 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tiwei Bie , Mateusz Guzik Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> In-Reply-To: <20141103064052.GA1739@freebsd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 08:14:26 -0000 On 11/3/14, 2:40 PM, Tiwei Bie wrote: > On Mon, Nov 03, 2014 at 06:19:08AM +0100, Mateusz Guzik wrote: >> On Mon, Nov 03, 2014 at 12:02:05PM +0800, Tiwei Bie wrote: >> >>> @@ -657,6 +657,7 @@ TAILQ_HEAD(sysctl_ctx_list, sysctl_ctx_entry); >>> #define KERN_PROC_UMASK 39 /* process umask */ >>> #define KERN_PROC_OSREL 40 /* osreldate for process binary */ >>> #define KERN_PROC_SIGTRAMP 41 /* signal trampoline location */ >>> +#define KERN_PROC_CWD 42 /* process current working directory */ >>> >>> why are you using a fixed sysctl MIB number? I thought we were moving towards dynamic sysctls when we add new ones. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 08:41:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FC475C2; Mon, 3 Nov 2014 08:41:35 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72202DB5; Mon, 3 Nov 2014 08:41:34 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id n3so5752087wiv.6 for ; Mon, 03 Nov 2014 00:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=jf21Ev/FHb1aRnVYEMMrSJywI1m+4etC9uR4sO3h7C4=; b=lEU/BTZhlvJpM1uaWeTEWqfzXpWCGmOv4pUKUf2ribeo4ELsyQlDIukwNhxLbsbBKg 6ZdDVrvPukjiMoPFTNACSBQKyvZQCEyaEme48cW814rJo0+lk8QcmF7KlZYnfndV6OMg M7KT950HGu9nw7nckg1QDfkQNjb277MYgDLmrehtyPS+BrDe9BnEK6IJUPL39GrntPkc dTwiTa0U09IclxA82AZUPoR4/mi4ejo77ugNZm4PyV6bEegBGisDa3cV3Uc3cSMoOqmW YctmHrahB7rHF0SB0YJ3saS16F3g9E+XkYNiLD0RVK0ElmzeXwv8A07ZznwGcp74KNZF NmfQ== X-Received: by 10.194.63.145 with SMTP id g17mr47589832wjs.80.1415004092646; Mon, 03 Nov 2014 00:41:32 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id f6sm7926356wix.5.2014.11.03.00.41.31 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 03 Nov 2014 00:41:31 -0800 (PST) Date: Mon, 3 Nov 2014 09:41:29 +0100 From: Mateusz Guzik To: Julian Elischer Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103084129.GF29497@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Julian Elischer , Tiwei Bie , freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <5457394E.4050905@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5457394E.4050905@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Tiwei Bie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 08:41:35 -0000 On Mon, Nov 03, 2014 at 04:14:06PM +0800, Julian Elischer wrote: > On 11/3/14, 2:40 PM, Tiwei Bie wrote: > >On Mon, Nov 03, 2014 at 06:19:08AM +0100, Mateusz Guzik wrote: > >>On Mon, Nov 03, 2014 at 12:02:05PM +0800, Tiwei Bie wrote: > >> > >>>@@ -657,6 +657,7 @@ TAILQ_HEAD(sysctl_ctx_list, sysctl_ctx_entry); > >>> #define KERN_PROC_UMASK 39 /* process umask */ > >>> #define KERN_PROC_OSREL 40 /* osreldate for process binary */ > >>> #define KERN_PROC_SIGTRAMP 41 /* signal trampoline location */ > >>>+#define KERN_PROC_CWD 42 /* process current working directory */ > >>> > why are you using a fixed sysctl MIB number? > I thought we were moving towards dynamic sysctls when we add new ones. > We are? KERN_PROC_* seems to be a complete list with SIGTRAMP added last year. I guess we can do it with OID_AUTO, if there will be any need we can switch it back to a static var. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 08:53:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03E0284F for ; Mon, 3 Nov 2014 08:53:13 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 11F98E94 for ; Mon, 3 Nov 2014 08:53:11 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygCnVzxsQldU4j7HAA--.18549S2; Mon, 03 Nov 2014 16:53:05 +0800 (CST) Date: Mon, 3 Nov 2014 16:52:35 +0800 From: Tiwei Bie To: Mateusz Guzik Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103085235.GA85851@freebsd> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141103080526.GE29497@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygCnVzxsQldU4j7HAA--.18549S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw43tFy3uFWxCr1UZw45Awb_yoW8ZF17pF ZxArZ8XF4UJF4UGF4qvrs8G3Z0ywnaqr1vgrW0v3ZxAFn8Zr4fZr42kr1j9Fyru3y5Z395 Cw48Ka1Iyw1UKaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Cr0_Gr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCY02Avz4vE14v_GFyl42xK82IY c2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8gdbUUUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQURAVQhl8yZCAAMsn Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 08:53:13 -0000 On Mon, Nov 03, 2014 at 09:05:26AM +0100, Mateusz Guzik wrote: > > > > #2. Patch for tmux: > > > > diff --git a/osdep-freebsd.c b/osdep-freebsd.c > > index d596eab..4178f01 100644 > > --- a/osdep-freebsd.c > > +++ b/osdep-freebsd.c > > @@ -132,6 +132,46 @@ error: > > return (NULL); > > } > > > > +#ifdef KERN_PROC_CWD > > +char * > > +osdep_get_cwd(int fd) > > +{ > > + static char wd[PATH_MAX]; > > + pid_t pgrp; > > + int mib[4]; > > + size_t len; > > + struct kinfo_file *info; > > + char *buf; > > + int error; > > + > > + if ((pgrp = tcgetpgrp(fd)) == -1) > > + return (NULL); > > + > > + mib[0] = CTL_KERN; > > + mib[1] = KERN_PROC; > > + mib[2] = KERN_PROC_CWD; > > Take a look at osdep-openbsd. This should be done along with > declaration. > > > + mib[3] = pgrp; > > + > > + error = sysctl(mib, 4, NULL, &len, NULL, 0); > > + if (error) > > + return (NULL); > > + > > + buf = malloc(len); > > + if (buf == NULL) > > + return (NULL); > > + error = sysctl(mib, 4, buf, &len, NULL, 0); > > + if (error) { > > + free(buf); > > + return (NULL); > > + } > > + > > + info = (struct kinfo_file *)buf; > > + strlcpy(wd, info->kf_path, sizeof wd); > > + > > + free(buf); > > Why? Just have static kinfo_file. There is no need to allocate or copy > anything, nor to query for size. > Sorry, my patch for tmux is messy... :-( My new patch: diff --git a/osdep-freebsd.c b/osdep-freebsd.c index d596eab..46f6f3f 100644 --- a/osdep-freebsd.c +++ b/osdep-freebsd.c @@ -132,6 +132,21 @@ error: return (NULL); } +#ifdef KERN_PROC_CWD +char * +osdep_get_cwd(int fd) +{ + static struct kinfo_file info; + int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_CWD, 0 }; + size_t len = sizeof info; + + if ((name[3] = tcgetpgrp(fd)) == -1) + return (NULL); + if (sysctl(name, 4, &info, &len, NULL, 0) != 0) + return (NULL); + return (info.kf_path); +} +#else /* !KERN_PROC_CWD */ char * osdep_get_cwd(int fd) { @@ -157,6 +172,7 @@ osdep_get_cwd(int fd) free(info); return (NULL); } +#endif /* KERN_PROC_CWD */ struct event_base * osdep_event_init(void) -- 2.1.0 Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 09:09:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF86D22F; Mon, 3 Nov 2014 09:09:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59DAFFF5; Mon, 3 Nov 2014 09:09:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sA399gID097884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2014 11:09:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA399gID097884 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA399fhZ097883; Mon, 3 Nov 2014 11:09:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 3 Nov 2014 11:09:40 +0200 From: Konstantin Belousov To: Mateusz Guzik , Julian Elischer , Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103090940.GI53947@kib.kiev.ua> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <5457394E.4050905@freebsd.org> <20141103084129.GF29497@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141103084129.GF29497@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 09:09:48 -0000 On Mon, Nov 03, 2014 at 09:41:29AM +0100, Mateusz Guzik wrote: > On Mon, Nov 03, 2014 at 04:14:06PM +0800, Julian Elischer wrote: > > why are you using a fixed sysctl MIB number? > > I thought we were moving towards dynamic sysctls when we add new ones. > > > > We are? KERN_PROC_* seems to be a complete list with SIGTRAMP added last > year. > > I guess we can do it with OID_AUTO, if there will be any need we can > switch it back to a static var. I am very curious how would you make kern.proc.cwd auto, while still using kern.proc leaf. And more important question is, why ? From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 10:20:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE591B62; Mon, 3 Nov 2014 10:20:11 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A4B89BC; Mon, 3 Nov 2014 10:20:10 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so10080280wgh.11 for ; Mon, 03 Nov 2014 02:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=z0cP0gsnY29DeIA36bzjQiZzSm0s3Uf5vKOhmmILVtU=; b=WEz0gBjfD//3y5mgfI4JvHSkr7vKZMV6AuzdJRIayFd+lAQJU/WUC6qQ5Iv9IlyO8w eIdbCV9YAyN+ytEPeJm4Z4rCz2s7Av2flfSs2LRSDg+K8u4OaUDN6WrIGI4KnSpb9/oo RRQvz5xWjFb7+y4YAjfR4Q4FNR46lQaoRJWESVxgee9MPwARevJFepAt/9v/IYYRG5iW FfSsdv+/Y+DhvlJc9lNACeBoDMzm1mtUMQym+yEga4X3bkTzKxD3knf+Z+0zjumCUqBY yPhS0hjqXwRPfTDwYuiXFGIgwGZxWhB4e2lvkN2QedPKVC3P9PEM357YRoDOE1OosAWQ WYZQ== X-Received: by 10.180.86.38 with SMTP id m6mr14962768wiz.65.1415010008401; Mon, 03 Nov 2014 02:20:08 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id ws2sm21645135wjc.32.2014.11.03.02.20.07 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 03 Nov 2014 02:20:07 -0800 (PST) Date: Mon, 3 Nov 2014 11:20:05 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103102005.GI29497@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , Julian Elischer , Tiwei Bie , freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <5457394E.4050905@freebsd.org> <20141103084129.GF29497@dft-labs.eu> <20141103090940.GI53947@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141103090940.GI53947@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Tiwei Bie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 10:20:11 -0000 On Mon, Nov 03, 2014 at 11:09:40AM +0200, Konstantin Belousov wrote: > On Mon, Nov 03, 2014 at 09:41:29AM +0100, Mateusz Guzik wrote: > > On Mon, Nov 03, 2014 at 04:14:06PM +0800, Julian Elischer wrote: > > > why are you using a fixed sysctl MIB number? > > > I thought we were moving towards dynamic sysctls when we add new ones. > > > > > > > We are? KERN_PROC_* seems to be a complete list with SIGTRAMP added last > > year. > > > > I guess we can do it with OID_AUTO, if there will be any need we can > > switch it back to a static var. > > I am very curious how would you make kern.proc.cwd auto, while > still using kern.proc leaf. And more important question is, why ? Unclear what you mean. I just tested with marking it OID_AUTO and it works. Userspace code does sysctlbyname to look it up and sysctl + mib[3] = pid to call, no problems that I can see. I'm not a fan of this because of the need for lookup for what is a compiled in and always available sysctl. I only said we can do OID_AUTO because of Julian's complaint. Was about to do some search for apparent agreement to not add more static sysctls, but your reply suggests there was no such thing. That said, I prefer static version. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 10:40:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C527D7C0; Mon, 3 Nov 2014 10:40:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6742BC3E; Mon, 3 Nov 2014 10:40:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sA3AeqdO019187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2014 12:40:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA3AeqdO019187 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA3Aeqn7019185; Mon, 3 Nov 2014 12:40:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 3 Nov 2014 12:40:52 +0200 From: Konstantin Belousov To: Mateusz Guzik , Julian Elischer , Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103104052.GL53947@kib.kiev.ua> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <5457394E.4050905@freebsd.org> <20141103084129.GF29497@dft-labs.eu> <20141103090940.GI53947@kib.kiev.ua> <20141103102005.GI29497@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141103102005.GI29497@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 10:40:58 -0000 On Mon, Nov 03, 2014 at 11:20:05AM +0100, Mateusz Guzik wrote: > On Mon, Nov 03, 2014 at 11:09:40AM +0200, Konstantin Belousov wrote: > > On Mon, Nov 03, 2014 at 09:41:29AM +0100, Mateusz Guzik wrote: > > > On Mon, Nov 03, 2014 at 04:14:06PM +0800, Julian Elischer wrote: > > > > why are you using a fixed sysctl MIB number? > > > > I thought we were moving towards dynamic sysctls when we add new ones. > > > > > > > > > > We are? KERN_PROC_* seems to be a complete list with SIGTRAMP added last > > > year. > > > > > > I guess we can do it with OID_AUTO, if there will be any need we can > > > switch it back to a static var. > > > > I am very curious how would you make kern.proc.cwd auto, while > > still using kern.proc leaf. And more important question is, why ? > > Unclear what you mean. I just tested with marking it OID_AUTO and it > works. Typical caller of other sysctls from kern.proc family does (slightly edited code from libunwind): int mib[4], error, ret; size_t len, len1; len = 0; mib[0] = CTL_KERN; mib[1] = KERN_PROC; mib[2] = KERN_PROC_VMMAP; mib[3] = pid; > > Userspace code does sysctlbyname to look it up and sysctl + mib[3] = pid to > call, no problems that I can see. Yes, but currently userspace does not need to do this dance (for other kern.proc sysctls). > > I'm not a fan of this because of the need for lookup for what is a > compiled in and always available sysctl. > > I only said we can do OID_AUTO because of Julian's complaint. Was about > to do some search for apparent agreement to not add more static sysctls, > but your reply suggests there was no such thing. It is reasonable to not manage allocation of oids for things which are hard or impossible to statically manage, e.g. the leafs from dynamically loaded modules, or leafs describing the device tree on the machine, where structure of the tree depends on the local conditions. Trying to enforce this rule for oids where only static tree is used only complicates life for consumers without any benefits for code clarity or extensibility. > > That said, I prefer static version. Agree. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 11:03:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70AEEED9 for ; Mon, 3 Nov 2014 11:03:59 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F43CE3D for ; Mon, 3 Nov 2014 11:03:58 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA3B3pMg022726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 3 Nov 2014 03:03:54 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5457610F.8070003@freebsd.org> Date: Mon, 03 Nov 2014 19:03:43 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov , Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [maybe spam] Re: [PATCH] Finish the task 'sysctl reporting current working directory' References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <5457394E.4050905@freebsd.org> <20141103084129.GF29497@dft-labs.eu> <20141103090940.GI53947@kib.kiev.ua> In-Reply-To: <20141103090940.GI53947@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 11:03:59 -0000 On 11/3/14, 5:09 PM, Konstantin Belousov wrote: > On Mon, Nov 03, 2014 at 09:41:29AM +0100, Mateusz Guzik wrote: >> On Mon, Nov 03, 2014 at 04:14:06PM +0800, Julian Elischer wrote: >>> why are you using a fixed sysctl MIB number? >>> I thought we were moving towards dynamic sysctls when we add new ones. >>> >> We are? KERN_PROC_* seems to be a complete list with SIGTRAMP added last >> year. >> >> I guess we can do it with OID_AUTO, if there will be any need we can >> switch it back to a static var. > I am very curious how would you make kern.proc.cwd auto, while > still using kern.proc leaf. And more important question is, why ? I had the impression we were using dynamic sysctls in preference to static ones. My memory was that phk set things up so you could add new items and have them not collide with static items. If it's acceptable to do statics, then that's fine, it's just that I haven't seen a static one added for ages. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 11:05:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0D7F194 for ; Mon, 3 Nov 2014 11:05:52 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A88C0E59 for ; Mon, 3 Nov 2014 11:05:52 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA3B5jsk022914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 3 Nov 2014 03:05:49 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54576181.5010405@freebsd.org> Date: Mon, 03 Nov 2014 19:05:37 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov , Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [maybe spam] Re: [PATCH] Finish the task 'sysctl reporting current working directory' References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <5457394E.4050905@freebsd.org> <20141103084129.GF29497@dft-labs.eu> <20141103090940.GI53947@kib.kiev.ua> <20141103102005.GI29497@dft-labs.eu> <20141103104052.GL53947@kib.kiev.ua> In-Reply-To: <20141103104052.GL53947@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 11:05:53 -0000 On 11/3/14, 6:40 PM, Konstantin Belousov wrote: > On Mon, Nov 03, 2014 at 11:20:05AM +0100, Mateusz Guzik wrote: >> On Mon, Nov 03, 2014 at 11:09:40AM +0200, Konstantin Belousov wrote: >>> On Mon, Nov 03, 2014 at 09:41:29AM +0100, Mateusz Guzik wrote: >>>> On Mon, Nov 03, 2014 at 04:14:06PM +0800, Julian Elischer wrote: >>>>> why are you using a fixed sysctl MIB number? >>>>> I thought we were moving towards dynamic sysctls when we add new ones. >>>>> >>>> We are? KERN_PROC_* seems to be a complete list with SIGTRAMP added last >>>> year. >>>> >>>> I guess we can do it with OID_AUTO, if there will be any need we can >>>> switch it back to a static var. >>> I am very curious how would you make kern.proc.cwd auto, while >>> still using kern.proc leaf. And more important question is, why ? >> Unclear what you mean. I just tested with marking it OID_AUTO and it >> works. > Typical caller of other sysctls from kern.proc family does > (slightly edited code from libunwind): > > int mib[4], error, ret; > size_t len, len1; > > len = 0; > mib[0] = CTL_KERN; > mib[1] = KERN_PROC; > mib[2] = KERN_PROC_VMMAP; > mib[3] = pid; > >> Userspace code does sysctlbyname to look it up and sysctl + mib[3] = pid to >> call, no problems that I can see. > Yes, but currently userspace does not need to do this dance (for other > kern.proc sysctls). > >> I'm not a fan of this because of the need for lookup for what is a >> compiled in and always available sysctl. >> >> I only said we can do OID_AUTO because of Julian's complaint. Was about >> to do some search for apparent agreement to not add more static sysctls, >> but your reply suggests there was no such thing. > It is reasonable to not manage allocation of oids for things which are > hard or impossible to statically manage, e.g. the leafs from dynamically > loaded modules, or leafs describing the device tree on the machine, > where structure of the tree depends on the local conditions. > > Trying to enforce this rule for oids where only static tree is used > only complicates life for consumers without any benefits for code > clarity or extensibility. > >> That said, I prefer static version. > Agree. I withdraw my comment.. :-) > > From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 4 09:52:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E658D2E8 for ; Tue, 4 Nov 2014 09:52:04 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 104F5258 for ; Tue, 4 Nov 2014 09:52:03 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygAXiT23oVhUx5XNAA--.19170S2; Tue, 04 Nov 2014 17:51:55 +0800 (CST) From: Tiwei Bie To: mjguzik@gmail.com Subject: [PATCH] Finish the task 'Embedd group table into struct ucred' Date: Tue, 4 Nov 2014 17:51:26 +0800 Message-Id: <1415094686-39302-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.2 X-CM-TRANSID: LkAmygAXiT23oVhUx5XNAA--.19170S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Cr4xCr1DWrW8JFW3Kr4xXrb_yoW8tw4Dpa 9Yyw15KF47J34DGr97t3yqvr4Iyw1ruFyDG3yrZr1aqryftF15AF15ZFWYkryYgF1rGr43 tF1fAw18Ar93A3JanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Cr0_Gr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_GFWl42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMI IF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU5g4S3UUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQURAVQhl8y9PQABs7 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 09:52:05 -0000 Hi, Mateusz! I have finished the task: Embedd group table into struct ucred [1]. This is an explanation of my patch: In crextend(), when n <= XU_NGROUPS, I did such updates directly: cr->cr_groups = cr->cr_smallgroups; cr->cr_agroups = XU_NGROUPS; Because there is a check in the front of this function: if (n <= cr->cr_agroups) return; So when n <= XU_NGROUPS, cr->cr_groups would never point to the memory allocated by malloc(), and it won't need to be freed. Following is my patch: diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c index 9b2bcd8..76d2cfc 100644 --- a/sys/kern/kern_prot.c +++ b/sys/kern/kern_prot.c @@ -1864,7 +1864,8 @@ crfree(struct ucred *cr) #ifdef MAC mac_cred_destroy(cr); #endif - free(cr->cr_groups, M_CRED); + if (cr->cr_groups != cr->cr_smallgroups) + free(cr->cr_groups, M_CRED); free(cr, M_CRED); } } @@ -1976,6 +1977,12 @@ crextend(struct ucred *cr, int n) if (n <= cr->cr_agroups) return; + if (n <= XU_NGROUPS) { + cr->cr_groups = cr->cr_smallgroups; + cr->cr_agroups = XU_NGROUPS; + return; + } + /* * We extend by 2 each time since we're using a power of two * allocator until we need enough groups to fill a page. @@ -1997,7 +2004,7 @@ crextend(struct ucred *cr, int n) cnt = roundup2(n, PAGE_SIZE / sizeof(gid_t)); /* Free the old array. */ - if (cr->cr_groups) + if (cr->cr_groups && cr->cr_groups != cr->cr_smallgroups) free(cr->cr_groups, M_CRED); cr->cr_groups = malloc(cnt * sizeof(gid_t), M_CRED, M_WAITOK | M_ZERO); diff --git a/sys/sys/ucred.h b/sys/sys/ucred.h index 81e4520..a6531c4 100644 --- a/sys/sys/ucred.h +++ b/sys/sys/ucred.h @@ -37,6 +37,8 @@ struct loginclass; +#define XU_NGROUPS 16 + /* * Credentials. * @@ -64,13 +66,12 @@ struct ucred { struct auditinfo_addr cr_audit; /* Audit properties. */ gid_t *cr_groups; /* groups */ int cr_agroups; /* Available groups */ + gid_t cr_smallgroups[XU_NGROUPS]; /* storage for small groups */ }; #define NOCRED ((struct ucred *)0) /* no credential available */ #define FSCRED ((struct ucred *)-1) /* filesystem credential */ #endif /* _KERNEL || _WANT_UCRED */ -#define XU_NGROUPS 16 - /* * Flags for cr_flags. */ -- 2.1.0 [1] https://wiki.freebsd.org/JuniorJobs#Embedd_group_table_into_struct_ucred Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 4 10:01:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAA687D5 for ; Tue, 4 Nov 2014 10:01:36 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FDBF3C6 for ; Tue, 4 Nov 2014 10:01:36 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so14541478wgh.10 for ; Tue, 04 Nov 2014 02:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=94zJZBaX+8LUYCuM9JIWi855P9c1aZzfp4tHlS9opEM=; b=p/jy0VUFVgSi5e9t4RwH6ZBb+GYslS18SKaBF1p/aFEWg0PQGE+BxDdHDM8lSMQTG5 ite9xl1N4Cg+K8pDmG5corSjppUxO0zrOPRJpqAt0ZI5hgvg1Zixnd6isptJGu/9J83C CYXc4pEMoKdiYSflVPGsLWKbKTX9fh0G4YpVLissyHszTWxqcUBnPZe6CVmX9mY4Bmci jsIhop9qg0+SEPQwwi/BBBy1RmPeCoesfG0LaLZcSTH59riZZRc3dRAxfD2c7cUUYQQq gIROWj7gi7eO/YmjqJO41WuOxm+PQbqUqyq6vzZkKKqM8FOjvaT7Xk1NffavpQt3ZRCR Q07w== X-Received: by 10.194.77.4 with SMTP id o4mr55664749wjw.41.1415095293798; Tue, 04 Nov 2014 02:01:33 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id cv7sm10201518wjc.3.2014.11.04.02.01.32 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 04 Nov 2014 02:01:33 -0800 (PST) Date: Tue, 4 Nov 2014 11:01:30 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'Embedd group table into struct ucred' Message-ID: <20141104100130.GC4032@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org References: <1415094686-39302-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1415094686-39302-1-git-send-email-btw@mail.ustc.edu.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 10:01:37 -0000 On Tue, Nov 04, 2014 at 05:51:26PM +0800, Tiwei Bie wrote: > diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c > index 9b2bcd8..76d2cfc 100644 > --- a/sys/kern/kern_prot.c > +++ b/sys/kern/kern_prot.c > @@ -1864,7 +1864,8 @@ crfree(struct ucred *cr) > #ifdef MAC > mac_cred_destroy(cr); > #endif > - free(cr->cr_groups, M_CRED); > + if (cr->cr_groups != cr->cr_smallgroups) > + free(cr->cr_groups, M_CRED); > free(cr, M_CRED); > } > } > @@ -1976,6 +1977,12 @@ crextend(struct ucred *cr, int n) > if (n <= cr->cr_agroups) > return; > > + if (n <= XU_NGROUPS) { > + cr->cr_groups = cr->cr_smallgroups; > + cr->cr_agroups = XU_NGROUPS; > + return; > + } > + This should be initialized in crget, which should no longer call this function. > /* > * We extend by 2 each time since we're using a power of two > * allocator until we need enough groups to fill a page. > @@ -1997,7 +2004,7 @@ crextend(struct ucred *cr, int n) > cnt = roundup2(n, PAGE_SIZE / sizeof(gid_t)); > > /* Free the old array. */ > - if (cr->cr_groups) > + if (cr->cr_groups && cr->cr_groups != cr->cr_smallgroups) > free(cr->cr_groups, M_CRED); It is no longer possible for cr_groups to be NULL. > > cr->cr_groups = malloc(cnt * sizeof(gid_t), M_CRED, M_WAITOK | M_ZERO); > diff --git a/sys/sys/ucred.h b/sys/sys/ucred.h > index 81e4520..a6531c4 100644 > --- a/sys/sys/ucred.h > +++ b/sys/sys/ucred.h > @@ -37,6 +37,8 @@ > > struct loginclass; > > +#define XU_NGROUPS 16 > + > /* > * Credentials. > * > @@ -64,13 +66,12 @@ struct ucred { > struct auditinfo_addr cr_audit; /* Audit properties. */ > gid_t *cr_groups; /* groups */ > int cr_agroups; /* Available groups */ > + gid_t cr_smallgroups[XU_NGROUPS]; /* storage for small groups */ > }; > #define NOCRED ((struct ucred *)0) /* no credential available */ > #define FSCRED ((struct ucred *)-1) /* filesystem credential */ > #endif /* _KERNEL || _WANT_UCRED */ > > -#define XU_NGROUPS 16 > - > /* > * Flags for cr_flags. > */ > -- > 2.1.0 > > [1] https://wiki.freebsd.org/JuniorJobs#Embedd_group_table_into_struct_ucred > > Tiwei Bie > -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 4 10:37:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7570452B for ; Tue, 4 Nov 2014 10:37:27 +0000 (UTC) Received: from mailomat.net (mailomat.net [81.20.89.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6B29965 for ; Tue, 4 Nov 2014 10:37:26 +0000 (UTC) X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] X-Cloudmark-Analysis: v=2.1 cv=RYepVTdv c=1 sm=1 tr=0 a=/nRDZZJyYxTE/j0HnTmKXw==:117 a=/nRDZZJyYxTE/j0HnTmKXw==:17 a=ZDwDCB9QlRsA:10 a=QX6QvZ3GsOUA:10 a=JysbXFYnAAAA:8 a=dAPAsP0gAAAA:8 a=1nuwWpZKx9z2IqmGlNgA:9 a=-1EdB9_SJqHDtoFH:21 a=vwMqeqj540qMYe-7:21 a=QEXdDO2ut3YA:10 a=gfHpuMcyBAOUHJ6S:21 a=_W_S_7VecoQA:10 a=qfQzaZuGX9vIp4vycI4A:9 a=ZVk8-NSrHBgA:10 Received: from [194.39.192.125] (account bnc-mail@mailrelay.mailomat.net HELO bnc.net) by mailomat.net (CommuniGate Pro SMTP 6.0.9) with ESMTPSA id 68142712 for freebsd-hackers@freebsd.org; Tue, 04 Nov 2014 11:37:22 +0100 X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] Received: from [192.168.200.188] (account ap@bnc.net HELO [192.168.200.188]) by bnc.net (CommuniGate Pro SMTP 6.0.9) with ESMTPSA id 7222491 for freebsd-hackers@freebsd.org; Tue, 04 Nov 2014 11:37:22 +0100 From: Achim Patzner Content-Type: multipart/signed; boundary="Apple-Mail=_3D93C828-7C1D-4612-83FB-507303D96559"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: UEFI booting Message-Id: Date: Tue, 4 Nov 2014 11:37:21 +0100 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 10:37:27 -0000 --Apple-Mail=_3D93C828-7C1D-4612-83FB-507303D96559 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! With a bunch of extremely cheap machines like the Zotac pico getting to = the market which only support 32 bit EFI shells (greetings from = Microsoft =E2=80=93 that way you can get a free Windows 8.1 for them) it = would be nice to produce some 32 bit EFI boot loader for them. I could = use a GRUB boot stage but that doesn=E2=80=99t look very FreeBSD to me). = Bonus points if the 32 bit loader could launch an amd64 kernel. Is there = anyone who created a memory stick image for that kind of environment or = who would be willing to do so? (And yes, those pico dwarves are better somehow faster than the low-end = boxes of the other Zotac series, so they are quite a good product even = if regarding their limitations. Achim --Apple-Mail=_3D93C828-7C1D-4612-83FB-507303D96559 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFaTCCBWUw ggNNoAMCAQICAwyteTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMzAxMDIwOTQ1MTVaFw0x NTAxMDIwOTQ1MTVaMDMxFjAUBgNVBAMTDUFjaGltIFBhdHpuZXIxGTAXBgkqhkiG9w0BCQEWCmFw QGJuYy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCemZ2gCwrtE8FYdD42ApLp AyRBcfTJHRaU5R/rTbpBTIbDQn4ESOg0697sOlMjiNlzgvuTJeGDSd6DLREb5pJqqNyzW5kTu1yN dzI8442GxyZAYImcXpQNvvA5OxH4GRwzcjlIie5TDZll1pA+OQwDfPWeosfUugHaDU6KuX6QhrJx JYdweO7ZOb9jL2iJGco3QCQKPoqbLt+NmIyV48DsB12H7oW7NI9E5CfiRQqMioVVUvkRWL2w+1MQ +ymaXl0KOqRZOzhKYJpoRmLxO/hKgBTn2MsEqtqMp5gemM3hRKF14MSo85nNqMv25AYJapkENazR hUmISG+1y6/goSJNAgMBAAGjggE6MIIBNjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93 d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUF BwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6 Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMBUGA1UdEQQOMAyBCmFwQGJuYy5uZXQwDQYJKoZI hvcNAQEFBQADggIBAMmLFZrEKQJqqmh+r8IzcfPl04h4ArE8O+I0BTN0r22hy4izV+F2Qvkwy02g uM8ylmUdCdIFXUQ8joPVT3RJqZ/NmDsdbFq4RziDbF/C219RfTRL1nWcNxudGA4vSLbuBTxD2bSx BkmjRdmpGm3EGwRp7bLtnONuTVBxK7TDculECUbm0Bwh9RAtZr/Gqk5arj5oO0oI9vKdRDVWCUxF m1kS7gwGfVtv2DKFDh3VBqB6kXfx5nP/LOcb7Rwpu4GzBU/e1OFswha9maU9Qi/9URX07Q47dOBc pqhNh5pW12kfeZPO7lcGqfYq08Ub/mKaJcAEaoyD2ILDDhzeeOK3QDlKC56lEt8MW4swef6/MPUh +WuofauNhBXoecf5XonGNuKEhbSmSykSzwoEBdBAO6QUtnpLTlYSeO3Xg/bYfbwJCGkUnd0q+2Q1 fQpN+RxkYqQCb5XaV9Fz7cU4u36Rc/AMDXr+qXEyvOqB7OzeTgjq06VMNQ+mIrGCS9rb7OQmB1o7 8PCOVTqE8z77Du4Bh14wG/SP/kat5IJSuDFjvFT/C8ro46pOfczfq/Eb4QSktwtbD7+Qlh4p/e0B n4nyK1M1MyDnQxzv2XvmWfwoi0tUP2dkT30YtUuucWYFzRO1erg4tVd4xW0ShP1VtynFyWQcPaLT LvWc/0VML6hcaWRuMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyteTAJBgUrDgMCGgUAoIIBhzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMDQxMDM3MjJaMCMG CSqGSIb3DQEJBDEWBBSpMKN/TweEohnzUkoQF3VfEuTabDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkx EDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UE AxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMrXkwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMrXkwDQYJKoZIhvcN AQEBBQAEggEAhIPS6m/qO1Wf/MDbEQe9qWzmJCYI9E8XIu6Cd6JCJeWINDtyk2+WR2N/viY7D0pH ufyswsYMBNIduvxSRdWVB/1KGQg0c5jVz4lN+8OULD/D411GbqkiIdVa4Hb9098GssqplIS0xgS9 dm++y71yVawGlCCoWq32+r7dNjj5Kc7IOvwmh5OkZv8Zk8DR02z9AMdpOc1doSdjvY/kA9Y/+N04 KgPVWwv6iDt6/oeDp9RkKo6zs+nj4ZJ3jTKyVKVm0+2VYphi2hjFuc8U2089zUCmW4tzrfcKR1ej x3zvkDEDDnszE7lCi7q97cv2XMfCDHDQay0IO51GBswg8QGLCQAAAAAAAA== --Apple-Mail=_3D93C828-7C1D-4612-83FB-507303D96559-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 4 12:42:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B4403AA for ; Tue, 4 Nov 2014 12:42:36 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 07B89BBA for ; Tue, 4 Nov 2014 12:42:34 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygAXiT2KyVhUnEbOAA--.19213S2; Tue, 04 Nov 2014 20:41:52 +0800 (CST) Date: Tue, 4 Nov 2014 20:41:20 +0800 From: Tiwei Bie To: Mateusz Guzik Subject: Re: [PATCH] Finish the task 'Embedd group table into struct ucred' Message-ID: <20141104124120.GA11252@freebsd> References: <1415094686-39302-1-git-send-email-btw@mail.ustc.edu.cn> <20141104100130.GC4032@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141104100130.GC4032@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygAXiT2KyVhUnEbOAA--.19213S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tr1fJrW7Wr1fXFWxtry7ZFb_yoW5JFWxpa 97t3y8KF43J34UJryktayvvF4xZw1F9a4DC3yrur1aqrn3tF1fZF15urWYkrWqgF1rGw1U KF1fAw1Utr93Aa7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Cr0_Gr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCY02Avz4vE14v_Xr1l42xK82IY c2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8Q_-DUUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQURAVQhl8y9PQAGs8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 12:42:36 -0000 On Tue, Nov 04, 2014 at 11:01:30AM +0100, Mateusz Guzik wrote: > On Tue, Nov 04, 2014 at 05:51:26PM +0800, Tiwei Bie wrote: > > diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c > > index 9b2bcd8..76d2cfc 100644 > > --- a/sys/kern/kern_prot.c > > +++ b/sys/kern/kern_prot.c > > @@ -1864,7 +1864,8 @@ crfree(struct ucred *cr) > > #ifdef MAC > > mac_cred_destroy(cr); > > #endif > > - free(cr->cr_groups, M_CRED); > > + if (cr->cr_groups != cr->cr_smallgroups) > > + free(cr->cr_groups, M_CRED); > > free(cr, M_CRED); > > } > > } > > @@ -1976,6 +1977,12 @@ crextend(struct ucred *cr, int n) > > if (n <= cr->cr_agroups) > > return; > > > > + if (n <= XU_NGROUPS) { > > + cr->cr_groups = cr->cr_smallgroups; > > + cr->cr_agroups = XU_NGROUPS; > > + return; > > + } > > + > > This should be initialized in crget, which should no longer call this > function. Sorry for my delay... Yeah, you are right. I didn't notice it... :-( My new patch: diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c index 9b2bcd8..c83af66 100644 --- a/sys/kern/kern_prot.c +++ b/sys/kern/kern_prot.c @@ -1817,7 +1817,9 @@ crget(void) #ifdef MAC mac_cred_init(cr); #endif - crextend(cr, XU_NGROUPS); + cr->cr_groups = cr->cr_smallgroups; + cr->cr_agroups = XU_NGROUPS; + return (cr); } @@ -1864,7 +1866,8 @@ crfree(struct ucred *cr) #ifdef MAC mac_cred_destroy(cr); #endif - free(cr->cr_groups, M_CRED); + if (cr->cr_groups != cr->cr_smallgroups) + free(cr->cr_groups, M_CRED); free(cr, M_CRED); } } @@ -1997,7 +2000,7 @@ crextend(struct ucred *cr, int n) cnt = roundup2(n, PAGE_SIZE / sizeof(gid_t)); /* Free the old array. */ - if (cr->cr_groups) + if (cr->cr_groups != cr->cr_smallgroups) free(cr->cr_groups, M_CRED); cr->cr_groups = malloc(cnt * sizeof(gid_t), M_CRED, M_WAITOK | M_ZERO); diff --git a/sys/sys/ucred.h b/sys/sys/ucred.h index 81e4520..a6531c4 100644 --- a/sys/sys/ucred.h +++ b/sys/sys/ucred.h @@ -37,6 +37,8 @@ struct loginclass; +#define XU_NGROUPS 16 + /* * Credentials. * @@ -64,13 +66,12 @@ struct ucred { struct auditinfo_addr cr_audit; /* Audit properties. */ gid_t *cr_groups; /* groups */ int cr_agroups; /* Available groups */ + gid_t cr_smallgroups[XU_NGROUPS]; /* storage for small groups */ }; #define NOCRED ((struct ucred *)0) /* no credential available */ #define FSCRED ((struct ucred *)-1) /* filesystem credential */ #endif /* _KERNEL || _WANT_UCRED */ -#define XU_NGROUPS 16 - /* * Flags for cr_flags. */ -- 2.1.0 Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 5 14:28:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE89BD02; Wed, 5 Nov 2014 14:28:09 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B16BD192; Wed, 5 Nov 2014 14:28:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com A90747590E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1415197687; bh=RzIFDK8SsGi9K3Kql9teE7ZNePrbrAznqHdDgii/3g8=; h=Date:From:To:Subject; b=ao/D/ci1OQLXr2KNusLWgARKauIR1aFw+OWpJWAUKN4rW25r2uV+BO1bHWIwS0unL Y71YAimOq3FKq+vHv7CWHK7x7ciKf8kcOfgRXbeLeHyhOMVUB74SF1IrsQyCa3cBfD sHfr2cLAM2rRVnBon0FCJjh3Py2illjdXoLvNrl4= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 05 Nov 2014 15:28:07 +0100 From: Ilya Bakulin To: freebsd-pf@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Checksumming outgoing packets in PF vs in =?UTF-8?Q?ip=5B=36=5D?= =?UTF-8?Q?=5Foutput?= Organization: Deglitch Networks Message-ID: X-Sender: ilya@bakulin.de X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:28:10 -0000 Hi all, I have been hit by this 2-year-old bug with PF and 'scrub reassemble tcp' on IPv6 connections: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172648 I have been able to trace it down to the modifications of timestamp values by timestamp modulation code [1]. If I remove those two pf_change_a() calls in the output path (pd->dir == PF_OUT) then everything works as it should, except that the timestamps are not modulated which is kinda sucks. Of course it was interesting what does the upstream PF do (@ OpenBSD). Seems they have made the decision to leave the task of recalculating the checksums for outgoing packets to ip[6]_output, because currently the code there overwrites the checksum anyway. This seems a correct way to me. pf should not longer do any checksum updates in inbound and outbound path. For inbound path, it should however check the checksum correctness and set a flag in mbuf csum flags so the tcp[6]_input doesn't try to verify it. In this case even if we modify something while applying TS modulation or sequence number modulation or something else in PF the upper-layer won't bailout because it will see that the checksum was already verified and won't try to verify it once again. OpenBSD does it this way and they seem to be happy. For now, I decided to leave the inbound path as-is and instead wanted to fix the outbound path. The patch [2] solves the problem described in [2] in the following way: 1) Hijack the last argument of pf_change_a() so that it doesn't update the checksum of the packet; 2) When updating the timestamps in pf_normalize_tcp_stateful() call pf_change_a() in "no-update-checksum" mode; 3) In pf_check_out() remove the checks for CSUM_DELAY_DATA -- don't calculate the checksum in any case. Such fix should be done in pf_check6_out() as well, but in my test setup I haven't seen that flag anyway. In future we probably should implement pf_change_a changes the same or similar way OpenBSD does it. [1] https://github.com/freebsd/freebsd/blob/49c137f7be5791eee8102395257cdf48b40c81f7/sys/netpfil/pf/pf_norm.c#L1569 [2] http://dl.bakulin.de/freebsd/pf_fix_reass_tcp_ipv6.diff From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 08:13:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71B3BEF0 for ; Thu, 6 Nov 2014 08:13:36 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3A587A6 for ; Thu, 6 Nov 2014 08:13:35 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id n3so679350wiv.6 for ; Thu, 06 Nov 2014 00:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=w+339epwBdTpprOD1LXBS+dMjbqbbNcpdbxrcQSgJug=; b=l12KoWzxbIYLt8DanEJLjWn16W8gL09CNopHYFu9IVgX+AWb5Pp+eA62MS7wn4d2gi 2M0iYVCibt1DFIpdyFFUBiAHKBKBndoXAm2/5+dMgPuinqD91rMH3vm1mPFRFgCXXnql lhuep85xGqb5nCijdYqKtiNfzfZlm7ZfE9n1Qpb8vivdyusVLHBL5k0C1C7FKtfAwx/u 9jJQt4Kr84WyUZRKkKkDbPRvF+8ZKrHiyHWIKlV45Dw6Ciyv4A85orpPtdrj7EvCQ/Ya frAVbqYENxGNwRfJn1o0ZxBfl4KzIXwBD3qBjKYa9ntpJmrx8bmQVCr0sS77D+oizr/a afWQ== X-Received: by 10.180.108.13 with SMTP id hg13mr37887214wib.27.1415261614429; Thu, 06 Nov 2014 00:13:34 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fv2sm7344395wib.2.2014.11.06.00.13.33 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 06 Nov 2014 00:13:33 -0800 (PST) Date: Thu, 6 Nov 2014 09:13:31 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106081330.GA12284@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141103085235.GA85851@freebsd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 08:13:36 -0000 On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: kernel changes got in in r274167 Please submit tmux patch to bugzilla. > > diff --git a/osdep-freebsd.c b/osdep-freebsd.c > index d596eab..46f6f3f 100644 > --- a/osdep-freebsd.c > +++ b/osdep-freebsd.c > @@ -132,6 +132,21 @@ error: > return (NULL); > } > > +#ifdef KERN_PROC_CWD > +char * > +osdep_get_cwd(int fd) > +{ > + static struct kinfo_file info; > + int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_CWD, 0 }; > + size_t len = sizeof info; > + > + if ((name[3] = tcgetpgrp(fd)) == -1) > + return (NULL); > + if (sysctl(name, 4, &info, &len, NULL, 0) != 0) > + return (NULL); > + return (info.kf_path); > +} > +#else /* !KERN_PROC_CWD */ > char * > osdep_get_cwd(int fd) > { > @@ -157,6 +172,7 @@ osdep_get_cwd(int fd) > free(info); > return (NULL); > } > +#endif /* KERN_PROC_CWD */ > > struct event_base * > osdep_event_init(void) -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 08:58:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBE92828 for ; Thu, 6 Nov 2014 08:58:40 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 12CACBE7 for ; Thu, 6 Nov 2014 08:58:38 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygA3FxQpOFtULXTcAA--.2046S2; Thu, 06 Nov 2014 16:58:23 +0800 (CST) Date: Thu, 6 Nov 2014 16:57:50 +0800 From: Tiwei Bie To: Mateusz Guzik Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106085750.GA52132@freebsd> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> <20141106081330.GA12284@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141106081330.GA12284@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygA3FxQpOFtULXTcAA--.2046S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Jry8WFWrJryrtFyfWr15Arb_yoWkZwc_Ww 47GFy3Zr4DAr18Cwn8t34Fy3sxKF1DJws5Wrs0ya4xAr98JFWfKr97Crn3ZrWfWrySgrW2 krs5tan2gF1qvjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb7kYjsxI4VW3JwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWxJVW8Jr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxkIecxEwVAFwVW8ZwCF04k20xvY 0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUcOJ5UUUUU X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUTAVQhl82hrQAGsz Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 08:58:41 -0000 On Thu, Nov 06, 2014 at 09:13:31AM +0100, Mateusz Guzik wrote: > On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: > > kernel changes got in in r274167 > > Please submit tmux patch to bugzilla. > Thanks! I have submitted the tmux patch to bugzilla [1]. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194858 > > > > diff --git a/osdep-freebsd.c b/osdep-freebsd.c > > index d596eab..46f6f3f 100644 > > --- a/osdep-freebsd.c > > +++ b/osdep-freebsd.c > > @@ -132,6 +132,21 @@ error: > > return (NULL); > > } > > > > +#ifdef KERN_PROC_CWD > > +char * > > +osdep_get_cwd(int fd) > > +{ > > + static struct kinfo_file info; > > + int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_CWD, 0 }; > > + size_t len = sizeof info; > > + > > + if ((name[3] = tcgetpgrp(fd)) == -1) > > + return (NULL); > > + if (sysctl(name, 4, &info, &len, NULL, 0) != 0) > > + return (NULL); > > + return (info.kf_path); > > +} > > +#else /* !KERN_PROC_CWD */ > > char * > > osdep_get_cwd(int fd) > > { > > @@ -157,6 +172,7 @@ osdep_get_cwd(int fd) > > free(info); > > return (NULL); > > } > > +#endif /* KERN_PROC_CWD */ > > > > struct event_base * > > osdep_event_init(void) > > -- > Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 09:14:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4EBCC7A for ; Thu, 6 Nov 2014 09:14:21 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DC58DE9 for ; Thu, 6 Nov 2014 09:14:21 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so541947lbv.24 for ; Thu, 06 Nov 2014 01:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ENBa7hPw8Zj0Hr+2hjghUVSzXGk5D7nr5jViXTw2LCA=; b=gW7S4RI7/4S3fFqeGFt7wg6240MbVd4Ek1Kd/t2AFn8+khgg2Z2Bg/uK087ZNu9gMn P1t83WaA0WnhWIfYnOBKmrUvcduzRFQUZjRwUGBNRrR50go+MKfUxZRO7YSucrrud93I 0kOECYBWIbcYrLrUmWUBw31JGuim0LEl6l64QvV/exq0/fGbIhDAE8amSci+9EWvPUrs jI7hB2+PqshC6gaDLAgqRbJawBbTofQodmdRiRTVHsyw2oARRKc6T0LkkTjrrHbgzCNx ZZ3IelCB/Fs8S8K8VOaz2pDRWbkod+4Zf3OlsiIDc/pv31aEQ/DfhRJQLDJShYcAFpR5 FShQ== X-Received: by 10.112.169.6 with SMTP id aa6mr3619611lbc.29.1415265259142; Thu, 06 Nov 2014 01:14:19 -0800 (PST) Received: from brick.home (adbf211.neoplus.adsl.tpnet.pl. [79.184.5.211]) by mx.google.com with ESMTPSA id 2sm2307252lai.36.2014.11.06.01.14.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Nov 2014 01:14:18 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 6 Nov 2014 10:14:17 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106091417.GA4716@brick.home> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> <20141106081330.GA12284@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141106081330.GA12284@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:14:21 -0000 On 1106T0913, Mateusz Guzik wrote: > On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: > > kernel changes got in in r274167 > > Please submit tmux patch to bugzilla. Just wondering, why put the changes into tmux and not getcwd(3)? From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 09:21:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C3A4F81 for ; Thu, 6 Nov 2014 09:21:19 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7D09EDE for ; Thu, 6 Nov 2014 09:21:18 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id r20so803152wiv.3 for ; Thu, 06 Nov 2014 01:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=LhsilJUb8oZCgeARLyLw8CGZAHpnwbRUEYcH3IjqKRI=; b=h6N8yIa19ad6sz6vQX1d3GT0dPHisUapHRwStRuo/282Acb7+KzXXpM0ZWjrTxiQmV zvfXMvAfVwebEIxIkcWG4w+M7lSE3FkAPIr1aVGDnOaL9GDWxMDbIFuidNoIOWVAUwf/ 85b/2u7iTL5ovNG683C0BBoMHWH9n2ojHeP0aBj+yCxLqJ4b4tl2mICuPAx3Uzv52pwZ k8xfmcUk4M5v+TKe0egWtjtG0+1vQRAHPudUcTH95rJDH0v6+xiePI1w8VTJZXyN5aAq HujGixsMmSdixn+D7VO3BPTQr0CXHnbqoB3WpIh4EDl5tt80dCWdQD3u05v8OvzKEgr/ c+NA== X-Received: by 10.180.11.66 with SMTP id o2mr12785681wib.22.1415265677072; Thu, 06 Nov 2014 01:21:17 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id iz14sm18732328wic.23.2014.11.06.01.21.15 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 06 Nov 2014 01:21:16 -0800 (PST) Date: Thu, 6 Nov 2014 10:21:13 +0100 From: Mateusz Guzik To: Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106092113.GC12284@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> <20141106081330.GA12284@dft-labs.eu> <20141106091417.GA4716@brick.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141106091417.GA4716@brick.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:21:19 -0000 On Thu, Nov 06, 2014 at 10:14:17AM +0100, Edward Tomasz Napierała wrote: > On 1106T0913, Mateusz Guzik wrote: > > On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: > > > > kernel changes got in in r274167 > > > > Please submit tmux patch to bugzilla. > > Just wondering, why put the changes into tmux and not getcwd(3)? > tmux queries cwd of other processes -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 09:21:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26F651E0 for ; Thu, 6 Nov 2014 09:21:40 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A70D3EED for ; Thu, 6 Nov 2014 09:21:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sA69LYDv055006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2014 11:21:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA69LYDv055006 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA69LYQe055004; Thu, 6 Nov 2014 11:21:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 6 Nov 2014 11:21:34 +0200 From: Konstantin Belousov To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106092134.GL53947@kib.kiev.ua> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> <20141106081330.GA12284@dft-labs.eu> <20141106085750.GA52132@freebsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141106085750.GA52132@freebsd> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:21:40 -0000 On Thu, Nov 06, 2014 at 04:57:50PM +0800, Tiwei Bie wrote: > On Thu, Nov 06, 2014 at 09:13:31AM +0100, Mateusz Guzik wrote: > > On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: > > > > kernel changes got in in r274167 > > > > Please submit tmux patch to bugzilla. > > > > Thanks! I have submitted the tmux patch to bugzilla [1]. > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194858 This is incorrect way to use kern_proc_cwd. You should try the new sysctl, and on ENOENT fall back to the kern_proc_file. Expecting that the binary is run on the same machine where it was build is wrong. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 09:26:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B7A4323 for ; Thu, 6 Nov 2014 09:26:11 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 114A7F2E for ; Thu, 6 Nov 2014 09:26:11 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so839574wid.16 for ; Thu, 06 Nov 2014 01:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=7aYUYy7FY6MOtnb1j+xBYZkg+/722C/qRMEAnOs4ip0=; b=xNgurINFhQF60pAUdVKKY+U99ee+De1mTSAQGf8ajkIa6xYmKNCiYghs0vc6bOw4/V cD1r3K0m4s0EUZ1XrdSi7Gpc0rwnppN5xFztygbpswU4M/8BYBLi2W0UJKnXmP71el8x WDuKY1JNFNtB6CxCZ8Vrm6Yyfh7IqYRn6rQzrhgaWv25XlOorQ4OHIYvJHoJhYfOxq0n pZbHVreWZCO9J+d31Xhn5pNkmt8Tn8nxmQFZiAiHWmUKm4loIbM2qVNXKdFGKayZbTjf rTJEZfZNoOX6FjAAkfUgE9TnFcnhdvDEgCaFZ54M+xpo95V/njt5PjNMkXYLXmgG1f1+ 77LA== X-Received: by 10.194.239.164 with SMTP id vt4mr1522109wjc.131.1415265969379; Thu, 06 Nov 2014 01:26:09 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fq1sm18764984wib.12.2014.11.06.01.26.07 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 06 Nov 2014 01:26:08 -0800 (PST) Date: Thu, 6 Nov 2014 10:26:05 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106092605.GD12284@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , Tiwei Bie , freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> <20141106081330.GA12284@dft-labs.eu> <20141106085750.GA52132@freebsd> <20141106092134.GL53947@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141106092134.GL53947@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Tiwei Bie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:26:11 -0000 On Thu, Nov 06, 2014 at 11:21:34AM +0200, Konstantin Belousov wrote: > On Thu, Nov 06, 2014 at 04:57:50PM +0800, Tiwei Bie wrote: > > On Thu, Nov 06, 2014 at 09:13:31AM +0100, Mateusz Guzik wrote: > > > On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: > > > > > > kernel changes got in in r274167 > > > > > > Please submit tmux patch to bugzilla. > > > > > > > Thanks! I have submitted the tmux patch to bugzilla [1]. > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194858 > > This is incorrect way to use kern_proc_cwd. You should try the new > sysctl, and on ENOENT fall back to the kern_proc_file. Expecting > that the binary is run on the same machine where it was build is > wrong. > Fair point. Please keep kern_proc_cwd ifdefed and have a static var so that initial failure is remembered and the code knows not to execute it again. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 10:01:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ECC4C2B for ; Thu, 6 Nov 2014 10:01:53 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 6967F381 for ; Thu, 6 Nov 2014 10:01:51 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygBnbPTcRltUp+HcAA--.2797S2; Thu, 06 Nov 2014 18:01:06 +0800 (CST) Date: Thu, 6 Nov 2014 18:00:32 +0800 From: Tiwei Bie To: Konstantin Belousov Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106100032.GA80996@freebsd> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> <20141106081330.GA12284@dft-labs.eu> <20141106085750.GA52132@freebsd> <20141106092134.GL53947@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141106092134.GL53947@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygBnbPTcRltUp+HcAA--.2797S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Kw47Gw1rtF1DXr1rXFy7Jrb_yoW8ArWUpr Z7Cr13Xa1kJF15GF4vyrs5Wwn0kwnxtFnYqrWrWanIkF15Xr1fuw4Ykr1jvFy3urW5Z3s5 A3y3Gwn2k3yxt3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Cr0_Gr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCY02Avz4vE14v_Gw1l42xK82IY c2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1_Oz7UUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUTAVQhl82hrQASsn Cc: freebsd-hackers@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 10:01:53 -0000 On Thu, Nov 06, 2014 at 11:21:34AM +0200, Konstantin Belousov wrote: > On Thu, Nov 06, 2014 at 04:57:50PM +0800, Tiwei Bie wrote: > > On Thu, Nov 06, 2014 at 09:13:31AM +0100, Mateusz Guzik wrote: > > > On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: > > > > > > kernel changes got in in r274167 > > > > > > Please submit tmux patch to bugzilla. > > > > > > > Thanks! I have submitted the tmux patch to bugzilla [1]. > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194858 > > This is incorrect way to use kern_proc_cwd. You should try the new > sysctl, and on ENOENT fall back to the kern_proc_file. Expecting > that the binary is run on the same machine where it was build is > wrong. > Yeah, you are right. Following is my new patch, maybe it needs some style improvements. diff --git a/osdep-freebsd.c b/osdep-freebsd.c index d596eab..673ca98 100644 --- a/osdep-freebsd.c +++ b/osdep-freebsd.c @@ -133,7 +133,7 @@ error: } char * -osdep_get_cwd(int fd) +osdep_get_cwd_fallback(int fd) { static char wd[PATH_MAX]; struct kinfo_file *info = NULL; @@ -158,6 +158,31 @@ osdep_get_cwd(int fd) return (NULL); } +#ifdef KERN_PROC_CWD +char * +osdep_get_cwd(int fd) +{ + static struct kinfo_file info; + int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_CWD, 0 }; + size_t len = sizeof info; + + if ((name[3] = tcgetpgrp(fd)) == -1) + return (NULL); + if (sysctl(name, 4, &info, &len, NULL, 0) == -1) { + if (errno == ENOENT) + return (osdep_get_cwd_fallback(fd)); + return (NULL); + } + return (info.kf_path); +} +#else /* !KERN_PROC_CWD */ +char * +osdep_get_cwd(int fd) +{ + return (osdep_get_cwd_fallback(fd)); +} +#endif /* KERN_PROC_CWD */ + struct event_base * osdep_event_init(void) { -- 2.1.0 From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 11:14:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34E2C5B1 for ; Thu, 6 Nov 2014 11:14:06 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD59BD20 for ; Thu, 6 Nov 2014 11:14:05 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id a1so897082wgh.34 for ; Thu, 06 Nov 2014 03:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Itd2c6laezlxVg5kN9rTokMjoCtUr4XfS2Ow6Lj6tJs=; b=i1DfTftwWviBvbDLqZM3sVL0fKuX+b+pbDfkzGwx5JeWPSFnF/AelSFtnj+KDcpdh9 7hKlQ4aKd7WVovPzrQF8f34VA0W2FI7L2BxcbR7sLmho+p+KojZGkSudj2YARHcFAGbX LT6gosIou5LSwOTmJXb3njolrJnOVEKRaJMEDYeBqJPUHmnmAPMw3zN8ENx3WHHgpUhA 4y1WozCsj84mrZ10l/eatyw1Qgks7rRQlMBLs/77YrXCU/8ii5BnwyKBvSQKAyh4qyt5 he2w9QTvPo1yD78J1j/848cfSmeIk83Tswt8Gd9CQxVQMkiOxnIVl1Dvw++xTf9MLCBd lwMw== X-Received: by 10.194.110.4 with SMTP id hw4mr4590454wjb.102.1415272444050; Thu, 06 Nov 2014 03:14:04 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id ji10sm19105985wid.7.2014.11.06.03.14.00 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 06 Nov 2014 03:14:00 -0800 (PST) Date: Thu, 6 Nov 2014 12:13:58 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106111358.GF12284@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , Konstantin Belousov , freebsd-hackers@freebsd.org References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> <20141106081330.GA12284@dft-labs.eu> <20141106085750.GA52132@freebsd> <20141106092134.GL53947@kib.kiev.ua> <20141106100032.GA80996@freebsd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141106100032.GA80996@freebsd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 11:14:06 -0000 On Thu, Nov 06, 2014 at 06:00:32PM +0800, Tiwei Bie wrote: > On Thu, Nov 06, 2014 at 11:21:34AM +0200, Konstantin Belousov wrote: > > On Thu, Nov 06, 2014 at 04:57:50PM +0800, Tiwei Bie wrote: > > > On Thu, Nov 06, 2014 at 09:13:31AM +0100, Mateusz Guzik wrote: > > > > On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: > > > > > > > > kernel changes got in in r274167 > > > > > > > > Please submit tmux patch to bugzilla. > > > > > > > > > > Thanks! I have submitted the tmux patch to bugzilla [1]. > > > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194858 > > > > This is incorrect way to use kern_proc_cwd. You should try the new > > sysctl, and on ENOENT fall back to the kern_proc_file. Expecting > > that the binary is run on the same machine where it was build is > > wrong. > > > > Yeah, you are right. Following is my new patch, maybe it needs some > style improvements. > > diff --git a/osdep-freebsd.c b/osdep-freebsd.c > index d596eab..673ca98 100644 > --- a/osdep-freebsd.c > +++ b/osdep-freebsd.c > @@ -133,7 +133,7 @@ error: > } > > char * > -osdep_get_cwd(int fd) > +osdep_get_cwd_fallback(int fd) > { > static char wd[PATH_MAX]; > struct kinfo_file *info = NULL; > @@ -158,6 +158,31 @@ osdep_get_cwd(int fd) > return (NULL); > } > > +#ifdef KERN_PROC_CWD > +char * > +osdep_get_cwd(int fd) > +{ > + static struct kinfo_file info; > + int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_CWD, 0 }; > + size_t len = sizeof info; > + > + if ((name[3] = tcgetpgrp(fd)) == -1) > + return (NULL); > + if (sysctl(name, 4, &info, &len, NULL, 0) == -1) { > + if (errno == ENOENT) > + return (osdep_get_cwd_fallback(fd)); > + return (NULL); > + } > + return (info.kf_path); tmux calls this quite often and trying out this sysctl just to see it fail each time is a waste. have a static var to indicate the failure and to know when to fallback immediately. Also this probably should be reworked to obtain tcgetpgrp once and then decide which sysctl to use, but that's largely a perference matter. > +} > +#else /* !KERN_PROC_CWD */ > +char * > +osdep_get_cwd(int fd) > +{ > + return (osdep_get_cwd_fallback(fd)); > +} > +#endif /* KERN_PROC_CWD */ > + > struct event_base * > osdep_event_init(void) > { > -- > 2.1.0 > > -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 6 11:40:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 278B6BF4 for ; Thu, 6 Nov 2014 11:40:01 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 328D3F75 for ; Thu, 6 Nov 2014 11:39:59 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygCnVzwAXltUiGfdAA--.19608S2; Thu, 06 Nov 2014 19:39:52 +0800 (CST) Date: Thu, 6 Nov 2014 19:39:16 +0800 From: Tiwei Bie To: Mateusz Guzik Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141106113916.GA13209@freebsd> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <20141103080526.GE29497@dft-labs.eu> <20141103085235.GA85851@freebsd> <20141106081330.GA12284@dft-labs.eu> <20141106085750.GA52132@freebsd> <20141106092134.GL53947@kib.kiev.ua> <20141106100032.GA80996@freebsd> <20141106111358.GF12284@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141106111358.GF12284@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygCnVzwAXltUiGfdAA--.19608S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCFW7Cr4kZw43Cry8JFy7KFg_yoW5tF1Upr Z7AF4UXF4kJF1UGF4qywsYgFnYywnxtr95WrWru3ZxAFn0qr1furs0kr4j9Fyfu3yrZ34k Cw4UGw1Syw47t3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkYb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Cr0_Gr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCY02Avz4vE14v_Gw4l42xK82IY c2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s 026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF 0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0x vE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8I38UUUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUTAVQhl82hrQAYst Cc: Konstantin Belousov , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 11:40:01 -0000 On Thu, Nov 06, 2014 at 12:13:58PM +0100, Mateusz Guzik wrote: > On Thu, Nov 06, 2014 at 06:00:32PM +0800, Tiwei Bie wrote: > > On Thu, Nov 06, 2014 at 11:21:34AM +0200, Konstantin Belousov wrote: > > > On Thu, Nov 06, 2014 at 04:57:50PM +0800, Tiwei Bie wrote: > > > > On Thu, Nov 06, 2014 at 09:13:31AM +0100, Mateusz Guzik wrote: > > > > > On Mon, Nov 03, 2014 at 04:52:35PM +0800, Tiwei Bie wrote: > > > > > > > > > > kernel changes got in in r274167 > > > > > > > > > > Please submit tmux patch to bugzilla. > > > > > > > > > > > > > Thanks! I have submitted the tmux patch to bugzilla [1]. > > > > > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194858 > > > > > > This is incorrect way to use kern_proc_cwd. You should try the new > > > sysctl, and on ENOENT fall back to the kern_proc_file. Expecting > > > that the binary is run on the same machine where it was build is > > > wrong. > > > > > > > Yeah, you are right. Following is my new patch, maybe it needs some > > style improvements. > > > > diff --git a/osdep-freebsd.c b/osdep-freebsd.c > > index d596eab..673ca98 100644 > > --- a/osdep-freebsd.c > > +++ b/osdep-freebsd.c > > @@ -133,7 +133,7 @@ error: > > } > > > > char * > > -osdep_get_cwd(int fd) > > +osdep_get_cwd_fallback(int fd) > > { > > static char wd[PATH_MAX]; > > struct kinfo_file *info = NULL; > > @@ -158,6 +158,31 @@ osdep_get_cwd(int fd) > > return (NULL); > > } > > > > +#ifdef KERN_PROC_CWD > > +char * > > +osdep_get_cwd(int fd) > > +{ > > + static struct kinfo_file info; > > + int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_CWD, 0 }; > > + size_t len = sizeof info; > > + > > + if ((name[3] = tcgetpgrp(fd)) == -1) > > + return (NULL); > > + if (sysctl(name, 4, &info, &len, NULL, 0) == -1) { > > + if (errno == ENOENT) > > + return (osdep_get_cwd_fallback(fd)); > > + return (NULL); > > + } > > + return (info.kf_path); > > > tmux calls this quite often and trying out this sysctl just to see it > fail each time is a waste. have a static var to indicate the failure and > to know when to fallback immediately. > > Also this probably should be reworked to obtain tcgetpgrp once and then > decide which sysctl to use, but that's largely a perference matter. > A fallback indicator has been added. New patch: diff --git a/osdep-freebsd.c b/osdep-freebsd.c index d596eab..74b5c91 100644 --- a/osdep-freebsd.c +++ b/osdep-freebsd.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -132,8 +133,8 @@ error: return (NULL); } -char * -osdep_get_cwd(int fd) +static char * +osdep_get_cwd_fallback(int fd) { static char wd[PATH_MAX]; struct kinfo_file *info = NULL; @@ -158,6 +159,38 @@ osdep_get_cwd(int fd) return (NULL); } +#ifdef KERN_PROC_CWD +char * +osdep_get_cwd(int fd) +{ + static struct kinfo_file info; + static bool fallback = false; + int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_CWD, 0 }; + size_t len = sizeof info; + + if (fallback) + return (osdep_get_cwd_fallback(fd)); + + if ((name[3] = tcgetpgrp(fd)) == -1) + return (NULL); + + if (sysctl(name, 4, &info, &len, NULL, 0) == -1) { + if (errno == ENOENT) { + fallback = true; + return (osdep_get_cwd_fallback(fd)); + } + return (NULL); + } + return (info.kf_path); +} +#else /* !KERN_PROC_CWD */ +char * +osdep_get_cwd(int fd) +{ + return (osdep_get_cwd_fallback(fd)); +} +#endif /* KERN_PROC_CWD */ + struct event_base * osdep_event_init(void) { -- 2.1.0 Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 7 09:33:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4180CCE6; Fri, 7 Nov 2014 09:33:31 +0000 (UTC) Received: from gw.zefyris.com (sabik.zefyris.com [IPv6:2001:7a8:3c67:2::254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC59238D; Fri, 7 Nov 2014 09:33:30 +0000 (UTC) Received: from sekishi.zefyris.com (sekishi.zefyris.com [IPv6:2001:7a8:3c67:2::12]) by gw.zefyris.com (8.14.5/8.14.5) with ESMTP id sA793aC9258329; Fri, 7 Nov 2014 10:04:06 +0100 (CET) Date: Fri, 7 Nov 2014 10:03:36 +0100 From: Francois Tigeot To: "Alexander V. Chernikov" Subject: Re: faith(4) / faithd(8) removal Message-ID: <20141107090334.GA673044@sekishi.zefyris.com> References: <544E2FA4.8080003@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544E2FA4.8080003@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gw.zefyris.com [IPv6:2001:7a8:3c67:2::254]); Fri, 07 Nov 2014 10:04:06 +0100 (CET) Cc: "freebsd-net@freebsd.org" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 09:33:31 -0000 Hi, On Mon, Oct 27, 2014 at 03:42:28PM +0400, Alexander V. Chernikov wrote: > > I'd like to remove faith (IPv6/v4 translator) from base. Another data point: http://www.litech.org/ptrtd/ This project was similar to faith; the last release was in 2002 and it has been officially declared dead in 2010. The authors themselves recommend to use NAT64 instead. I'm pretty sure you can safely remove faith from base. -- Francois Tigeot From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 7 19:49:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A33C71B7 for ; Fri, 7 Nov 2014 19:49:34 +0000 (UTC) Received: from mail-qg0-x244.google.com (mail-qg0-x244.google.com [IPv6:2607:f8b0:400d:c04::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D61A2C3 for ; Fri, 7 Nov 2014 19:49:34 +0000 (UTC) Received: by mail-qg0-f68.google.com with SMTP id f51so661210qge.11 for ; Fri, 07 Nov 2014 11:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GviZd0zY9N7f69yprXvjredYJzc/pkaQrGXXLJhpPu0=; b=HiVX4Y/GS0goR6N/RjhgRi1+YtjuTcm+Ikv+DUEBWIyzAAwDbFBcee1ZvI7y8ASohc YR0qPLjrUZaxA1ihf8zjInKvydHNUtE/j+9tH7r/VAIkrn+PrdEXtjejM6t9vw8Xd9Ji T/RA1DVVj4D+7orfzi2ytCO5h1ll8cf8WWNd3S2Rlc1nHLJ+hHXLfDvaFdRBUiOXtZmP 9q+DYnShLcbnGXt8x7ifbww3K2R5/odEKz8QGm4nBEm98pphQC7JgDJUb77ig/RficKn huDx0fl1H0o2vaFNoN94z+hD2kvi/4sDlg2DDJcljgh777mmU3R9BEvb6ty2mnsrwtPI qK0A== MIME-Version: 1.0 X-Received: by 10.224.103.74 with SMTP id j10mr20536903qao.101.1415389773441; Fri, 07 Nov 2014 11:49:33 -0800 (PST) Received: by 10.140.174.69 with HTTP; Fri, 7 Nov 2014 11:49:33 -0800 (PST) Date: Fri, 7 Nov 2014 17:49:33 -0200 Message-ID: Subject: How to help the developers of FreeBSD that coding in the lowest level of computer programming that is used in the development of FreeBSD? From: true ware To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 19:49:34 -0000 Hello everyone I intend to develop a project based on FreeBSD that has the best quality possible , encoding until even in the lower level of programming of computers that currently is possible to encode, if the lowest level of programming of computers that is possible to encode currently is the microcode, try to encode in microcode, else, I try in encode binary code, else, try to encode in hex code ... But I not created this thread to discuss about the lower level of programming of computers that is possible to encode currently . I intend to help even the developers of FreeBSD that coding in the lowest level of computer programming that is used in the development of FreeBSD developing in the lowest level of computer programming that is used in the development of FreeBSD. How to help the developers of FreeBSD that coding in the lowest level of computer programming that is used in the development of FreeBSD? From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 7 22:57:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F4434A7 for ; Fri, 7 Nov 2014 22:57:03 +0000 (UTC) Received: from www.lemis.com (www.lemis.com [208.86.226.86]) by mx1.freebsd.org (Postfix) with ESMTP id 35627974 for ; Fri, 7 Nov 2014 22:57:02 +0000 (UTC) Received: from eureka.lemis.com (www.lemis.com [208.86.226.86]) by www.lemis.com (Postfix) with ESMTP id DFA071B72843; Fri, 7 Nov 2014 22:51:23 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 727D7F75F2; Sat, 8 Nov 2014 09:51:22 +1100 (EST) Date: Sat, 8 Nov 2014 09:51:22 +1100 From: Greg 'groggy' Lehey To: true ware Subject: Re: How to help the developers of FreeBSD that coding in the lowest level of computer programming that is used in the development of FreeBSD? Message-ID: <20141107225122.GA8070@eureka.lemis.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: None. Use the landline. WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:57:03 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 7 November 2014 at 17:49:33 -0200, true ware wrote: > Subject: Re: How to help the developers of FreeBSD that coding in the lowest level of computer programming that is used in the development of FreeBSD? This is really far too long a Subject: line for most MUAs. But at least it got my attention. > How to help the developers of FreeBSD that coding in the lowest > level of computer programming that is used in the development of > FreeBSD? I think the real question is "why". Where it's really necessary, we code in assembler. Anything lower than that is counterproductive. And for just about everything, C is the best choice. If you can come up with good arguments for your views, I'm sure people will listen. Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlRdTOkACgkQIubykFB6QiMgtQCgpy3b96ITmjrNj6XEwZJy0Lc3 Q30AnRh45m4ng1/YpG/qXzhDglq0RMKb =hFLq -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 8 00:23:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1050E509; Sat, 8 Nov 2014 00:23:17 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D92BD18C; Sat, 8 Nov 2014 00:23:16 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sA80NKf6084639; Fri, 7 Nov 2014 16:23:20 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD ports" , "FreeBSD CURRENT" , From: "Chris H" Subject: How exactly does the base toolchain determine WHICH language to build with? Date: Fri, 07 Nov 2014 16:23:20 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <6810431a15d054459a29d434dd22619e@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 00:23:17 -0000 Greetings, Sorry for the long title. I've been [needlessly] struggling with getting ports within the ports tree to build, on a fresh 11-CURRENT install from 2014-11-05. With custom KERNEL and WORLD built, and installed. Here's my situation, which has worked well since ~8.2; make.conf(5) WITHOUT_CLANG=true FAVORITE_COMPILER=gcc src.conf(5) WITHOUT_CLANG=true I'll neither argue, nor defend rational for w/o clang. To boring and out of scope for this thread. That said; I realize that lang/clang(33/34/35) is the default toolchain for 10+, and that's just fine by me. So I shouldn't be terribly surprised when install kernel/world, followed by make delete-old removes the clang built, or provided by the base install from the (initial) install procedure. But what _does_ surprise me, is that the install of lang/gcc-48 does _not_ become the compiler of choice with the above $ENV, after [seemingly] deleting clang. I understand that it may not be advisable to eliminate the default [base] toolchain. But leaving only remnants of clang, causes quite a bit of what I would consider POLA. Given that clang's bin files are [still] located in /usr/bin, while additional compilers are located in /usr/local/bin. All past installs -- even an older 11, did not exhibit this problem. What's changed? What's the rational, and how to best setup an effective build $ENV under the current circumstances? Or is this simply an [unintended] anomaly? Currently, the only way I can envision overcoming this, is by way of make.conf(5). Using the CC, CXX, and CPP directives. Which IMHO is not ideal. Thank you for all your time, and consideration, and sorry for the somewhat longish post. --Chris From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 8 02:09:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3548F770 for ; Sat, 8 Nov 2014 02:09:32 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 21738C20 for ; Sat, 8 Nov 2014 02:09:32 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id CC621341F83D for ; Fri, 7 Nov 2014 18:09:31 -0800 (PST) Message-ID: <545D7B5A.7090908@mu.org> Date: Fri, 07 Nov 2014 18:09:30 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: How to help the developers of FreeBSD that coding in the lowest level of computer programming that is used in the development of FreeBSD? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 02:09:32 -0000 Have you heard of Forth? -Alfred On 11/7/14, 11:49 AM, true ware wrote: > Hello everyone > > I intend to develop a project based on FreeBSD that has the best quality > possible , encoding until even in the lower level of programming of > computers that currently is possible to encode, if the lowest level of > programming of computers that is possible to encode currently is the > microcode, try to encode in microcode, else, I try in encode binary code, > else, try to encode in hex code ... > > But I not created this thread to discuss about the lower level of > programming of computers that is possible to encode currently . > > I intend to help even the developers of FreeBSD that coding in the lowest > level of computer programming that is used in the development of FreeBSD > developing in the lowest level of computer programming that is used in the > development of FreeBSD. > > How to help the developers of FreeBSD that coding in the lowest level of > computer programming that is used in the development of FreeBSD? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 8 04:50:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD1EE805; Sat, 8 Nov 2014 04:50:24 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98D58D51; Sat, 8 Nov 2014 04:50:24 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sA84oRB6004679; Fri, 7 Nov 2014 20:50:28 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Scot Hetzel In-Reply-To: References: <6810431a15d054459a29d434dd22619e@ultimatedns.net>, From: "Chris H" Subject: Re: How exactly does the base toolchain determine WHICH language to build with? Date: Fri, 07 Nov 2014 20:50:28 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <7ea810d33efa9b6c64d75cb08abdae93@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, FreeBSD CURRENT , FreeBSD ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 04:50:25 -0000 On Fri, 7 Nov 2014 22:39:27 -0600 Scot Hetzel wrote > On Fri, Nov 7, 2014 at 6:23 PM, Chris H wrote: > > Greetings, > > Sorry for the long title. I've been [needlessly] struggling > > with getting ports within the ports tree to build, on a > > fresh 11-CURRENT install from 2014-11-05. With custom > > KERNEL and WORLD built, and installed. > > Here's my situation, which has worked well since ~8.2; > > make.conf(5) > > WITHOUT_CLANG=true > > FAVORITE_COMPILER=gcc > > src.conf(5) > > WITHOUT_CLANG=true > > > > I'll neither argue, nor defend rational for w/o clang. To > > boring and out of scope for this thread. That said; I > > realize that lang/clang(33/34/35) is the default toolchain > > for 10+, and that's just fine by me. So I shouldn't be > > lang/clang(33/34/35) is not the default toolchain in 10+. 10+ uses a > version of clang that is included in the FreeBSD source (/usr/src). > > > terribly surprised when install kernel/world, followed by > > make delete-old removes the clang built, or provided by > > the base install from the (initial) install procedure. But > > what _does_ surprise me, is that the install of lang/gcc-48 > > does _not_ become the compiler of choice with the above > > $ENV, after [seemingly] deleting clang. I understand that > > FAVORITE_COMPILER is used by Mk/Uses/compiler.mk. > > If you want ports to build with lang/gcc-48, then you would need to > check that the ports you are trying to compile have either > USES=compiler or USES_GCC defined in their Makefile. Otherwise the > ports will use the compiler that is provided by the FreeBSD source > (gcc 2.4.x or clang). > > When WITHOUT_CLANG is defined in make.conf/src.conf. The FreeBSD > source will be built using gcc 2.4.x from the FreeBSD source. > /usr/bin/{cc,c++} will then be linked to the gcc versions. The ports > will then use this version to build if there is no USES_GCC or > USES=compiler in the ports Makefile. Perfect, and thank you very much, Scott, for the clarification. For what ever reason. Mine (CC,cc++,...) are linked to what's left of clang. I guess I'll need to try and dig deeper, and see if I can discover, why, and what happened. Just for the record. Re-reading my comment above, I realize that my statement regarding clang, might be interpreted as my having negative feelings about clang/llvm. For clarity, that is not the case. This install is targeted at development. As such, I want more granular control of what I build, and test with. So I'll actually be installing every version of lang/clang, and testing accordingly. Thank you again, Scott, for taking the time to respond. --Chris > > -- > DISCLAIMER: > > No electrons were maimed while sending this message. Only slightly bruised. > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 8 04:39:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 347B7603; Sat, 8 Nov 2014 04:39:29 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B98CFC86; Sat, 8 Nov 2014 04:39:28 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id y10so5211231wgg.2 for ; Fri, 07 Nov 2014 20:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7TnuqNMxWAM7BVOeMpbT7B6xHkWZ1tw/lORMFkuwPNE=; b=d5Q+WPCy99jcDGyTjLRTaP7uJlPU/u5F0L/QmxlUdeou8J1M6a8S+dm1MCsSKnhxSP P5Th+vVH3WU/M3eIboLSQmhVEoBXtQLlePfoheX2ugRyelSWc1ygQBvngm4eBmEYDScy FaTZljOYAgXfV7TBxCEHzMITTg8hicg0m7VUNQ7lI7IArcAOX52NsFaQQjOsJmipEYdc pNRxePkgawkCSh9s8C7RzqdLyYrNGNYAjSCUDc1Uzoe5hS5a980JG/9S5IX1jfRqmBIb +SXIc97jd38GuiYUsP68J3bUmMCv4dcP/cNesf3SM6VV27MNrWAdTjZytMYg3tTVM04D dugQ== MIME-Version: 1.0 X-Received: by 10.194.60.16 with SMTP id d16mr22809070wjr.13.1415421567201; Fri, 07 Nov 2014 20:39:27 -0800 (PST) Received: by 10.27.46.14 with HTTP; Fri, 7 Nov 2014 20:39:27 -0800 (PST) In-Reply-To: <6810431a15d054459a29d434dd22619e@ultimatedns.net> References: <6810431a15d054459a29d434dd22619e@ultimatedns.net> Date: Fri, 7 Nov 2014 22:39:27 -0600 Message-ID: Subject: Re: How exactly does the base toolchain determine WHICH language to build with? From: Scot Hetzel To: Chris H Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 08 Nov 2014 12:11:18 +0000 Cc: freebsd-hackers@freebsd.org, FreeBSD CURRENT , FreeBSD ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 04:39:29 -0000 On Fri, Nov 7, 2014 at 6:23 PM, Chris H wrote: > Greetings, > Sorry for the long title. I've been [needlessly] struggling > with getting ports within the ports tree to build, on a > fresh 11-CURRENT install from 2014-11-05. With custom > KERNEL and WORLD built, and installed. > Here's my situation, which has worked well since ~8.2; > make.conf(5) > WITHOUT_CLANG=true > FAVORITE_COMPILER=gcc > src.conf(5) > WITHOUT_CLANG=true > > I'll neither argue, nor defend rational for w/o clang. To > boring and out of scope for this thread. That said; I > realize that lang/clang(33/34/35) is the default toolchain > for 10+, and that's just fine by me. So I shouldn't be lang/clang(33/34/35) is not the default toolchain in 10+. 10+ uses a version of clang that is included in the FreeBSD source (/usr/src). > terribly surprised when install kernel/world, followed by > make delete-old removes the clang built, or provided by > the base install from the (initial) install procedure. But > what _does_ surprise me, is that the install of lang/gcc-48 > does _not_ become the compiler of choice with the above > $ENV, after [seemingly] deleting clang. I understand that FAVORITE_COMPILER is used by Mk/Uses/compiler.mk. If you want ports to build with lang/gcc-48, then you would need to check that the ports you are trying to compile have either USES=compiler or USES_GCC defined in their Makefile. Otherwise the ports will use the compiler that is provided by the FreeBSD source (gcc 2.4.x or clang). When WITHOUT_CLANG is defined in make.conf/src.conf. The FreeBSD source will be built using gcc 2.4.x from the FreeBSD source. /usr/bin/{cc,c++} will then be linked to the gcc versions. The ports will then use this version to build if there is no USES_GCC or USES=compiler in the ports Makefile. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 8 13:46:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5735C2D; Sat, 8 Nov 2014 13:46:29 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 765E8140; Sat, 8 Nov 2014 13:46:29 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::c850:5765:a731:a87d] (unknown [IPv6:2001:7b8:3a7:0:c850:5765:a731:a87d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 342F0B80A; Sat, 8 Nov 2014 14:46:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: How exactly does the base toolchain determine WHICH language to build with? From: Dimitry Andric In-Reply-To: <6810431a15d054459a29d434dd22619e@ultimatedns.net> Date: Sat, 8 Nov 2014 14:46:21 +0100 Content-Transfer-Encoding: 7bit Message-Id: <2D6D79A7-D05E-4DE2-A2B6-EFE261204B02@FreeBSD.org> References: <6810431a15d054459a29d434dd22619e@ultimatedns.net> To: Chris H X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-hackers@freebsd.org, FreeBSD CURRENT , FreeBSD ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 13:46:29 -0000 On 08 Nov 2014, at 01:23, Chris H wrote: > Sorry for the long title. I've been [needlessly] struggling > with getting ports within the ports tree to build, on a > fresh 11-CURRENT install from 2014-11-05. With custom > KERNEL and WORLD built, and installed. > Here's my situation, which has worked well since ~8.2; > make.conf(5) > WITHOUT_CLANG=true > FAVORITE_COMPILER=gcc > src.conf(5) > WITHOUT_CLANG=true If you don't want to use and build clang at all, I think you also need these two settings (at least on recent -CURRENT): WITHOUT_CLANG_BOOTSTRAP=foo WITHOUT_CLANG_IS_CC=foo The latter variable determines whether /usr/bin/cc, /usr/bin/c++ and so on are linked to clang or gcc. I suspect the root of all your problems is that you don't have this setting. > I'll neither argue, nor defend rational for w/o clang. To > boring and out of scope for this thread. That said; I > realize that lang/clang(33/34/35) is the default toolchain > for 10+, and that's just fine by me. So I shouldn't be > terribly surprised when install kernel/world, followed by > make delete-old removes the clang built, or provided by > the base install from the (initial) install procedure. But > what _does_ surprise me, is that the install of lang/gcc-48 > does _not_ become the compiler of choice with the above > $ENV, after [seemingly] deleting clang. It does not work that way. If you configure the base system to use gcc only, individual ports can decide that they need newer C++ support, or other features not available in the version of gcc in base (which is very old by now). In that case, they will use one of the gcc ports, or possibly even one of the clang ports. -Dimitry From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 8 20:52:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5AE81D2; Sat, 8 Nov 2014 20:52:19 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 766C9BA3; Sat, 8 Nov 2014 20:52:19 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sA8KqQrp087043; Sat, 8 Nov 2014 12:52:26 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Dimitry Andric In-Reply-To: <2D6D79A7-D05E-4DE2-A2B6-EFE261204B02@FreeBSD.org> References: <6810431a15d054459a29d434dd22619e@ultimatedns.net>, <2D6D79A7-D05E-4DE2-A2B6-EFE261204B02@FreeBSD.org> From: "Chris H" Subject: Re: How exactly does the base toolchain determine WHICH language to build with? Date: Sat, 08 Nov 2014 12:52:26 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <9135556ed9cef3ea7052a00d1b3b9120@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, FreeBSD CURRENT , FreeBSD ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 20:52:19 -0000 On Sat, 8 Nov 2014 14:46:21 +0100 Dimitry Andric wrote > On 08 Nov 2014, at 01:23, Chris H wrote: > > Sorry for the long title. I've been [needlessly] struggling > > with getting ports within the ports tree to build, on a > > fresh 11-CURRENT install from 2014-11-05. With custom > > KERNEL and WORLD built, and installed. > > Here's my situation, which has worked well since ~8.2; > > make.conf(5) > > WITHOUT_CLANG=true > > FAVORITE_COMPILER=gcc > > src.conf(5) > > WITHOUT_CLANG=true > > If you don't want to use and build clang at all, I think you also need > these two settings (at least on recent -CURRENT): > > WITHOUT_CLANG_BOOTSTRAP=foo > WITHOUT_CLANG_IS_CC=foo > > The latter variable determines whether /usr/bin/cc, /usr/bin/c++ and so > on are linked to clang or gcc. I suspect the root of all your problems > is that you don't have this setting. > > > > I'll neither argue, nor defend rational for w/o clang. To > > boring and out of scope for this thread. That said; I > > realize that lang/clang(33/34/35) is the default toolchain > > for 10+, and that's just fine by me. So I shouldn't be > > terribly surprised when install kernel/world, followed by > > make delete-old removes the clang built, or provided by > > the base install from the (initial) install procedure. But > > what _does_ surprise me, is that the install of lang/gcc-48 > > does _not_ become the compiler of choice with the above > > $ENV, after [seemingly] deleting clang. > > It does not work that way. If you configure the base system to use gcc > only, individual ports can decide that they need newer C++ support, or > other features not available in the version of gcc in base (which is > very old by now). In that case, they will use one of the gcc ports, > or possibly even one of the clang ports. Ahh. Thank you. It's now perfectly clear, and makes complete sense, now. For the record; I have nothing against clang/llvm, per se. I am just looking to obtain a bit more control over my environment. As this installation is intended for development purposes. In fact, I'll probably install all 3 versions of lang/clang. :) Oh, and GNC C, as well. Thank you again, for the reply. Now that I have also been informed about freebsd-toolchain@. I should probably take this opportunity to apologize for the noise, and thank all for their thoughtful replies. :) --Chris > > -Dimitry From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 8 22:06:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87240DCA; Sat, 8 Nov 2014 22:06:40 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 519A6217; Sat, 8 Nov 2014 22:06:40 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id hl2so14588801igb.10 for ; Sat, 08 Nov 2014 14:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Twg4OyqotN7nyG+DUZlEMXL1WhK2/xSeyg3YdD74Cho=; b=xaI3FaIOU0bpbrs5uX4zWT4BXs83LNbd5L8Wt9wiUVNko8kZoyM4M5ixZRNS62bHot sIQFIqRXcKrCwBTxhvoo696zzAS39eKO7IPYsnoFQBebvfuCou5B3jfSC9R3VYCcsSTn g5Fkhcrkp6JQormp9lY41NcyXbDjasyfGM2asrwiPjztkIvSdGr1fQfJucFdV6+OWMej EP8UiCPACj4+VHvUzNIh3vPDhU4Qu/G6fpcrNSCn1EwWG0c9QEnUmQE0oqenXh/1DUMH 2nl+2Buk4UO5FTsO21vqmGRBiF+Bu/8Utz67NENnr4p0C8TN7uBGQxy+NGUmcGVHBtuU QqeQ== MIME-Version: 1.0 X-Received: by 10.42.216.77 with SMTP id hh13mr20843188icb.31.1415484399714; Sat, 08 Nov 2014 14:06:39 -0800 (PST) Received: by 10.107.19.234 with HTTP; Sat, 8 Nov 2014 14:06:39 -0800 (PST) Date: Sat, 8 Nov 2014 14:06:39 -0800 Message-ID: Subject: DTrace: stack() does not print kernel module functions for i386 From: Shrikanth Kamath To: freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, avg@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 22:06:40 -0000 I verified this on a FreeBSD 10.0 STABLE, the stack() feature does not appear to print functions from kernel modules. I believe there is a glitch in libdtrace in the function "dt_module_update" (cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c). The section header address computation which is currently being done in the function dt_module_update for elf type ET_REL, a similar computation needs to be done for the ET_DYN maybe. I lack background on the elf types but for experiment sakes I changed the line @@ -948,7 +948,7 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_fil #if defined(__FreeBSD__) mapbase = (uintptr_t)k_stat->address; gelf_getehdr(dmp->dm_elf, &ehdr); - is_elf_obj = (ehdr.e_type == ET_REL); + is_elf_obj = (ehdr.e_type == ET_REL) || (ehdr.e_type == ET_DYN); if (is_elf_obj) { dmp->dm_sec_offsets = malloc(ehdr.e_shnum * sizeof(*dmp->dm_sec_offsets)); So from a previous run where I was running a dtrace one liner %dtrace -n 'fbt:hwpmc:: { stack(); }' The output without the above change shows a sample as 0 50825 pmc_find_process_descriptor:entry 0xc3c35bf5 <-- Address not matched to symbol kernel`syscall+0x48b kernel`0xc0fd2121 whereas with the above nit change to include ET_DYN for section offset adjustment I get the complete stack trace as 0 50825 pmc_find_process_descriptor:entry hwpmc.ko`pmc_hook_handler+0x6a5 <--address matched to symbol kernel`syscall+0x48b kernel`0xc0fd2121 I believe without the correct section offset adjustment the following check in the function dtrace_lookup_by_addr fails to match the address to the correct symbol if (addr - dmp->dm_text_va < dmp->dm_text_size || addr - dmp->dm_data_va < dmp->dm_data_size || addr - dmp->dm_bss_va < dmp->dm_bss_size) because dml->dm_text_va was not setup correctly in dt_module_update. Can somebody help clarify this? Reference: commit revision 210425. -- Shrikanth R K