Date: Thu, 14 Aug 2014 09:23:58 -0600 From: Warner Losh <imp@bsdimp.com> To: Phil Shafer <phil@juniper.net> Cc: Marcel Moolenaar <marcel@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net>, arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <746AC443-B255-47DD-8C24-3E3A32A5CC05@bsdimp.com> In-Reply-To: <201408141516.s7EFGE4a096197@idle.juniper.net> References: <201408141516.s7EFGE4a096197@idle.juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <phil@juniper.net> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?746AC443-B255-47DD-8C24-3E3A32A5CC05>