From owner-freebsd-arch@FreeBSD.ORG Thu Aug 14 08:53:07 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 9EC6292F; Thu, 14 Aug 2014 08:53:07 +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 254EA271A; Thu, 14 Aug 2014 08:53:06 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7E8qwvc099612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2014 11:52:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7E8qwvc099612 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7E8qvqE099611; Thu, 14 Aug 2014 11:52:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Aug 2014 11:52:57 +0300 From: Konstantin Belousov To: Phil Shafer Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <20140814085257.GN2737@kib.kiev.ua> References: <20140814052648.GM2737@kib.kiev.ua> <201408140606.s7E66XXA091972@idle.juniper.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aSnC4ZPPfhCvD8sN" Content-Disposition: inline In-Reply-To: <201408140606.s7E66XXA091972@idle.juniper.net> 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: 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 08:53:07 -0000 --aSnC4ZPPfhCvD8sN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 14, 2014 at 02:06:33AM -0400, Phil Shafer wrote: > Konstantin Belousov writes: > >Yes, the notes are used to communicate the information required by > >the dynamic linker to correctly activate the image. The mechanism has > >nothing to do with application-specific features, and overloading it for > >that purpose is severe and pointless layering violation. >=20 > The ELF spec says: >=20 > Note Section >=20 > Sometimes a vendor or system builder needs to mark an object > file with special information that other programs will check > for conformance, compatibility, etc. Sections of type SHT_NOTE > and program header elements of type PT_NOTE can be used for > this purpose. The note information in sections and program > header elements holds any number of entries, each of which is > an array of 4-byte words in the format of the target processor. > Labels appear below to help explain note information organization, > but they are not part of the specification. ELF standard scope is about build toolchain and C runtime, where the cited paragraph makes perfect sense. >=20 > Marking the binary with a libxo-specific note tells the caller that > the binary is capable of rendering its output in a non-traditional > style and gives the caller a means of triggering those styles of > output. In the libxo-enabled world, I see this as vital information > the caller needs to initialize the environment in which the command > will be run. Isn't this exactly the sort of information ELF targets > for note sections? 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 ? 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 ? Definitely, I do not see an addition of the fashion-of-the-day text-mangling output shattering enough to justify imposing the architecture violation. --aSnC4ZPPfhCvD8sN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT7HjpAAoJEJDCuSvBvK1BlY4P+gK4CHB71vO90ziLrLhVQm/m kTVLOoMKQoce46xHoeoePXHXBDzzurPKZUI9DyCjOTdNyjAxKvNm8yNb8TQrDSpd ASn4ztWJih5WHrOr1dAXwKLl6RKIDzUUQGvYQfpZbMgLQhLC7jHnC67v42YDN7CT 0DYY/VbSilvgThUNSfhvK3eQp846lOb2T6dEoc3/dDSeoM0WnkZnlpI//ztsy1wG U6hdolglbCm28rFvB3eMB2gIv6uGcwxjFn7EutkLZ4Qs7cxtG1dzFEpGIEDiBSfc Sr4hqLHcqnbPwAZdWGfhuKYBhOZaC4SAA4CefeBYNMhobYV+gFAFhuWlnkh6g5J+ riDupZcUM9e+YTbu2C2XxBGaTwIyCF7ESps89x5yhb46WikgVzjj9yNbh4VgAZk3 7EmsWaogZR6qRNKQdZimn28ksN42J/Ryu1PL7KG/e6cWK2b/kj2A2OmB78eBgEgy uKbzFD4XmCCkAEkbgl4D/LBZvEa1wRsnQaNSzMaChv0RCToixkaFdKAKqXbi3bvG RdRWZnaGqSxA21JnZWgcMDGuBNqpGt4yYwGxOebdCPcgi2TTik/PpqmYq4He2PyC 7ukjFTx6+RbFZlplIN7z/V2B4iKL/tlBWHbThBzC1FzNlsV1f8JQNlPTmFZado6C TYNJm4D056mDdGTTYieK =ANxL -----END PGP SIGNATURE----- --aSnC4ZPPfhCvD8sN--