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
[-- Attachment #1 --] Sorry for top posting, this really isn’t responsive to the minutia in the rest of the thread. I’m curious. Why isn’t this conversation about “foo —supports-xml” ? 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’s way more standardized than adding obscure notes that may or may not be allowed by the standard, but that we traditionally haven’t done, which requires tools that aren’t 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’s not a shell script wrapper for that tool that redirects to binaries that do support this, etc, etc etc. Basically, what does this ‘meta data’ really buy you that can’t be bought some other, more standard, more direct way that doesn’t 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 ? > > 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 > _______________________________________________ > 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" [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?746AC443-B255-47DD-8C24-3E3A32A5CC05>