From owner-freebsd-arch@FreeBSD.ORG Thu Aug 14 15:24:11 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB85FDE8 for ; Thu, 14 Aug 2014 15:24:11 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (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 55E242508 for ; Thu, 14 Aug 2014 15:24:11 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id h15so13860370igd.5 for ; Thu, 14 Aug 2014 08:24:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4E2RqfxhYsX/xyenQjLzzFNm09Bh6LZGoYIJjqwz6xU=; b=AAggTa06rjTTKR37MKnYhmPM634i49YsDYeHymzNaqyd+FOvwCi/ubcoS2WTZA2rq3 AOHoBuoLRCDDy7UEoaws4HCQab78NIZ6I5dBDhEsRmV51AStz31ifBSdF93rZQrOjql2 lel5IFFspkkZjwrRxp6hBkcCWISUSUaCKPmTdRMn3u6yOvb6oR9rDgnpl4VB+oX/iUaj 6fOJGUUI8CKznX35XZACBv4m2CdMT1HXhAnVHHpOtfDsZDaI9Q0h56DW6N1cny7lXahS omvPsdmGzynpp7iNPqJPZK2mMoDj2szked2Iha6xax2wiibiDRzzdUzKSJcDWdLPSpTo ATuA== X-Gm-Message-State: ALoCoQnlTQQ7RYIE/DJxzG+8mAHWDJ0ATyKblj5rbfU1Qc02Sl4DjffXEKL9A0hmXuRcNNUZSkO1 X-Received: by 10.50.61.145 with SMTP id p17mr17770128igr.41.1408029842333; Thu, 14 Aug 2014 08:24:02 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id nn13sm21379206igb.7.2014.08.14.08.23.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 08:24:00 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_086615EE-779B-42D1-901B-9B8227B36641"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML From: Warner Losh In-Reply-To: <201408141516.s7EFGE4a096197@idle.juniper.net> Date: Thu, 14 Aug 2014 09:23:58 -0600 Message-Id: <746AC443-B255-47DD-8C24-3E3A32A5CC05@bsdimp.com> References: <201408141516.s7EFGE4a096197@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1878.6) Cc: Marcel Moolenaar , John-Mark Gurney , "Simon J. Gerraty" , arch@freebsd.org, Poul-Henning Kamp , Konstantin Belousov 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:24:11 -0000 --Apple-Mail=_086615EE-779B-42D1-901B-9B8227B36641 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry for top posting, this really isn=92t responsive to the minutia in = the rest of the thread. I=92m curious. Why isn=92t this conversation about =93foo =97supports-xml=94= ? Why tag these commands with weird, non-standard things that need more = exotic tools to dig the information out. Why not have a standardized = command line option that prints nothing and returns 0 for success, or = whines and returns 1 for failure? That=92s way more standardized than = adding obscure notes that may or may not be allowed by the standard, but = that we traditionally haven=92t done, which requires tools that aren=92t = standardized and whose interface varies from one tool to the next. This = is true of asking about DT_NEEDED (which forces a specific library for = the implementation) as well as anything placed in the NOTES section. It = also assumes that you know the thing you are querying is an ELF = executable, that you can find it, that there=92s not a shell script = wrapper for that tool that redirects to binaries that do support this, = etc, etc etc. Basically, what does this =91meta data=92 really buy you that can=92t be = bought some other, more standard, more direct way that doesn=92t = enshrine so many hard-coded implementation decisions into the mix? Warner On Aug 14, 2014, at 9:16 AM, Phil Shafer wrote: > 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 ? >=20 > 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. >=20 >> 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 ? >=20 > Apologies; here is your original question: >=20 >>> 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 = ? >=20 > 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. >=20 > 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?". >=20 >> Definitely, I do not see an addition of the fashion-of-the-day >> text-mangling output shattering enough to justify imposing the >> architecture violation. >=20 > 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. >=20 > Thanks, > Phil > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" --Apple-Mail=_086615EE-779B-42D1-901B-9B8227B36641 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT7NSOAAoJEGwc0Sh9sBEAr9IQAMgYGxnStDoK9WpJGDuXE2Y7 bbLn4Abot42L5xlw7LDOJkT5EJA30uU84fqeA9qECLn2pPEV+9jyWJATUekRNlew Z8frd2WaB7od5soNdfGgmhEQFjYWNZb+fu6Kuk3X1E6cmVaEDGyb0SRh8mE6PW58 0gwSn1N3mAH8dvM0T3TclGezv9kR40zwOpVxXpVgyOCgfp4xSd0ySXE5MMZosVOQ N9Rnpf4XbzPFL04mNUN0kpgpUzRZtS3br28uh6kK0hylZ1ShebSpCN9QlCBOEwFM nix+Dsd1Y1XfDGGaiFWHpxM/uqplQaqHJnSzml0BUPSAl7ifckF8NBVhiED/NF1M iOh792EmRxSYRRwOtk3CSsUdrUPTSzCcuNxd40S31aJVt10Y3G47pTJPeeI7grbd Ad3eZAJe1N/QnIzxWMk6v7S+bZ99qy3ZjQ/KWgHZL88+u0/1lOmkW7PxdVm7TPiU 7njYKF8K0DGkkR0hyNO335c+0FOkms1N8ZtLFax8sMEGxgqeV9ssBQS9+vsxsj9j VkuCip2TQ6pfR8NWbkBwfMQFY4SWHAZzUcK0hoTprdkk4jZY9OoIRcSUIKFWhM7w xtHl56qp6SApjfnPUjq3dQp/tZllHSap4Q4rLzvXcgn/uaszo0m/BuLU/uUOpVSV f4ubkQ4haRuS3hzYZW47 =5OGR -----END PGP SIGNATURE----- --Apple-Mail=_086615EE-779B-42D1-901B-9B8227B36641--