From owner-freebsd-arch@FreeBSD.ORG Thu Aug 14 15:17:08 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD37F967; Thu, 14 Aug 2014 15:17:08 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B7DF2425; Thu, 14 Aug 2014 15:17:07 +0000 (UTC) Received: from BY2PR05CA009.namprd05.prod.outlook.com (10.242.32.39) by DM2PR05MB734.namprd05.prod.outlook.com (10.141.178.22) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 14 Aug 2014 15:16:59 +0000 Received: from BL2FFO11FD027.protection.gbl (2a01:111:f400:7c09::163) by BY2PR05CA009.outlook.office365.com (2a01:111:e400:2c2a::39) with Microsoft SMTP Server (TLS) id 15.0.1005.10 via Frontend Transport; Thu, 14 Aug 2014 15:16:58 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Thu, 14 Aug 2014 15:16:57 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 14 Aug 2014 08:16:36 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s7EFGOn86702; Thu, 14 Aug 2014 08:16:29 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id s7EFGE4a096197; Thu, 14 Aug 2014 11:16:14 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201408141516.s7EFGE4a096197@idle.juniper.net> To: Konstantin Belousov Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-Reply-To: <20140814085257.GN2737@kib.kiev.ua> Date: Thu, 14 Aug 2014 11:16:14 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(199003)(189002)(164054003)(561944003)(87936001)(81542001)(77982001)(74662001)(102836001)(110136001)(81342001)(107046002)(83072002)(74502001)(80022001)(48376002)(6806004)(53416004)(69596002)(106466001)(4396001)(86362001)(92726001)(81156004)(85306004)(84676001)(1411001)(76482001)(92566001)(50986999)(103666002)(64706001)(46102001)(54356999)(44976005)(105596002)(95666004)(83322001)(79102001)(21056001)(97736001)(76506005)(20776003)(85852003)(47776003)(99396002)(31966008)(50466002)(68736004); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB734; H:P-EMF01-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 03030B9493 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=phil@juniper.net; X-OriginatorOrg: juniper.net Cc: arch@freebsd.org, Poul-Henning Kamp , marcel@freebsd.org, John-Mark Gurney , "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:17:08 -0000 Konstantin Belousov writes: >How binary format has any relevance for an application level feature ? >What would you do with the binaries which permissions are 'r-s--x--x', >which is not unexpected for the tools which gather system information >and have to access things like /dev/mem ? This would clearly not make sense. Some meta-data should be in the file and some in the filesystem. Implementing the SF_SNAPSHOT file as a note section would be silly. But that doesn't imply that using a note section to facilitate proper construction of the environment for running a binary isn't reasonable. >You removed and did not answered a crusial question, which is a litmus >test for your proposal. Namely, how presence of the proposed note in >the binary is different from DT_NEEDED tag for your library ? Apologies; here is your original question: >>Using the static tagging for the dynamic application properties is wrong >>anyway. E.g., would you consider the mere fact that the binary is linked >>against your library, as the indication that your feature is supported ? >>If not, how does it differ from the presence of some additional note ? No, I'm not looking for something more explicit than a reference to a function in a library. I'm looking for an explicit marker that a binary supports working in a particular environment. That marker could be applied by having the developer link against a specific marking library, or by having a tool make the binary appropriately. But it should be something explicit. Re: DT_NEEDED: this section holds symbols for dynamic linking. It's content and meaning are explicitly given in the spec. The note section is intended for other generic information. It seems a reasonable place to put the answer to the question "can this binary make additional styles of output and how do I trigger that behavior?". >Definitely, I do not see an addition of the fashion-of-the-day >text-mangling output shattering enough to justify imposing the >architecture violation. It's partially opinion and perspective, but I don't see an architecture violation; I see the use of a generic mechanism to carry relevant information. And I see this addition as a modernization that allows better integration with fashionable tools like browsers and client/server architectures. Thanks, Phil