Date: Fri, 15 Aug 2014 07:44:52 -0700 From: Alfred Perlstein <bright@mu.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Marcel Moolenaar <marcel@freebsd.org>, Phil Shafer <phil@juniper.net>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net>, "arch@freebsd.org" <arch@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <D0921A8C-2D3B-4C9F-BB55-6C028F449DE5@mu.org> In-Reply-To: <20140815082501.GR2737@kib.kiev.ua> References: <201408131936.s7DJaA1r089174@idle.juniper.net> <20140814052648.GM2737@kib.kiev.ua> <16CE0543-0616-415D-9E68-EEB053DE4254@xcllnt.net> <20140815082501.GR2737@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Agree with kib.=20 Kib, one thing that I just don't understand is the point of even being able t= o query programs for libxo support. Does it make sense to you? =20 Sent from my iPhone > On Aug 15, 2014, at 1:25 AM, Konstantin Belousov <kostikbel@gmail.com> wro= te: >=20 >> On Thu, Aug 14, 2014 at 10:04:36AM -0700, Marcel Moolenaar wrote: >>=20 >> On Aug 13, 2014, at 10:26 PM, Konstantin Belousov <kostikbel@gmail.com> w= rote: >>>>=20 >>>> I know ELF "Note" elements can be used to carry vendor-specific >>>> data, but have no experience with them. Would it be reasonable to >>>> use them as a means of communicating this information to other bits >>>> of software? >>> No. >>=20 >> Too extreme. >>=20 >>>> Is FreeBSD using Notes for other information currently? >>> 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. Things should >>> not be done just because they could be done. >>=20 >> Too extreme. Life is a lot more subtle. Standards >> are as well. There are many examples in the real >> world where standards are interpreted a little >> more liberal than others may want to. When such >> result in (gratuitous) incompatibilities, we all >> interpret it as bad. But when it adds real value, >> you tend to find it in the next update of the >> standard. >=20 > Do you suggest that next revision of ELF standard starts talking > about app-level features ? >=20 >>=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 linke= d >>> 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 >> If we can eliminate static linking for libxo, than >> that is definitely easy. Easiest probably. The >> question becomes: is it acceptable to not support >> static linking for libxo? Or alternatively, is it >> acceptable to not be able to check for the feature >> on a static executable? > Let me clarify. I do not suggest to use DT_NEEDED for libxo (?) as the > alternative feature test, either. I consider both the proposed note > and the presence of dependency on libxo.so as equally wrong ways to > determine the perceived support for specific output formats. My point > was that note is essentially same as DT_NEEDED tag, with the same set of > architectural problems, but it is easier to see them for DT_NEEDED. >=20 > Static binaries is just a detail, and yes, I consider static linking > as place where we cannot hold an ABI guarantee. The good example > was kse libpthread, which broke statically linked threaded binaries. >=20 > My objections against use of ELF could be summarized as following: > - ELF is a binary standard for image activation and runtime system, not > for the app level features. >=20 > - Attempt to shoe-horn the discussed feature into binary format makes > the indicator cut of the actual feature. It is like the mark on the > plastic can, which may have no relation to the can content. From > this PoV, the options or special env variables are at the right > place. >=20 > - It is unportable. Why bind the pure data transformation library to > the platform ? What about Mach-O or COFF/PE platforms ? What if > FreeBSD decide to change binary format, or add support for a new > format, besides ELF ? What if the tool and consumer are of different > ABI ? E.g., one is 64 bit, another is 32bit. Usually, there is > support for less bits, but 32bit libelf or debugger or libunwind > or whatever usually have troubles reading 64bit ELF objects. >=20 >>=20 >> For the first I'm inclined to say yes, but not for >> the second. >=20 > In fact, since I already started talking on the subject, I > dislike the idea of adding the other text formats to existing > tools. Much more reasonable route, IMO, is to have a library to > interrogate system state and present the data in ABI-stable and > introspection-friendly way, without enforcing the >=20 > kernel->internal userspace structure->text serialization-> > text parsing ->some other internal userspace structure >=20 > path on the consumers. >=20 > If so inclined, some existing tools could be converted to use the > library and possibly libxo. But I suspect that the presence of the > library for system state and bindings for the most popular scripting > languages (which is facilitated by the introspection facilities, > to avoid the need of translating each ABI structure into each language > datatype) is the sweet spot for the current consumers of libxo > formatted output. There would be no need for running external tool, > determining if it is suitable, parsing its output, treat the text > output as ABI contract and so on.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0921A8C-2D3B-4C9F-BB55-6C028F449DE5>