Date: Fri, 15 Aug 2014 11:25:01 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Marcel Moolenaar <marcel@xcllnt.net> 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, Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <20140815082501.GR2737@kib.kiev.ua> In-Reply-To: <16CE0543-0616-415D-9E68-EEB053DE4254@xcllnt.net> References: <201408131936.s7DJaA1r089174@idle.juniper.net> <20140814052648.GM2737@kib.kiev.ua> <16CE0543-0616-415D-9E68-EEB053DE4254@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--6nfUOKxk8V1TQsEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. Do you suggest that next revision of ELF standard starts talking about app-level features ? >=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 link= ed > > 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. 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. 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. - 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. - 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 > For the first I'm inclined to say yes, but not for > the second. 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 kernel->internal userspace structure->text serialization-> text parsing ->some other internal userspace structure path on the consumers. 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. --6nfUOKxk8V1TQsEu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT7cPdAAoJEJDCuSvBvK1B4foP/jKJseCkwkXr1JZGiVdv/wjW 5jAeJCZHuBo7sqiFXAIWXZbbbJHcX9ww30HiDBjWLPAk/tsGguzgNiK7EeFXeKj1 bipABPMRWvspBJ4HgvfwFcNJ0iNq24EaMobh1tG2oby4OhIaS/ZbXxR3L0kbkAYl PMmEemWSuJZM+K0DxYuonVXm+YKrU+6GUZgDC6Sm/FvJUDhTu4wir0xNLEEz1ioi 5sSe1oKByxlItVKuvzIhtRX2j3tHhWcn+e13EC4fuEL0pufHyQUWyEfpUFmEuxxy lqBVlTTeubBhpL7FT6MvBu0JEu673q4ofsmDy76J2rBbEXG3BuslisZk7u38gg90 0lNuZekRZAFvjFtDTXaqYztkUoGNvZI4IR31fK835tjZVwtImxvLCtOYIJQ/1MDK KMTLIniglDnF1xbjngvj4kkShPe1YEAxPkO2RkD7LjZZp6ksIballGdjWFKeyImX PCenSmsK1j0YqCe5YWAuKbutoVQT2IT93m6RbFHibzjXf8RjJf5X67ZFitRSodFN 4bZM5WK/mrwejPlDJBIxcReOIpu9AkyOuOCZwnVJf3mR0AXoW9MzKJkL1npipbim wFHhj1Sy5pdgCU0Xr3mGW9gdvV0e/DJd4ebLcPa8vWvfxbQOvO1VoU7uU190wmA5 fL00mWEYBlQWNDHyQJs7 =RDy9 -----END PGP SIGNATURE----- --6nfUOKxk8V1TQsEu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140815082501.GR2737>