From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 14:45:07 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00E2CDE4; Fri, 15 Aug 2014 14:45:06 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DE813287D; Fri, 15 Aug 2014 14:45:06 +0000 (UTC) Received: from [10.0.1.107] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id EFC98346DE8B; Fri, 15 Aug 2014 07:45:05 -0700 (PDT) References: <201408131936.s7DJaA1r089174@idle.juniper.net> <20140814052648.GM2737@kib.kiev.ua> <16CE0543-0616-415D-9E68-EEB053DE4254@xcllnt.net> <20140815082501.GR2737@kib.kiev.ua> Mime-Version: 1.0 (1.0) In-Reply-To: <20140815082501.GR2737@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Alfred Perlstein Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Date: Fri, 15 Aug 2014 07:44:52 -0700 To: Konstantin Belousov Cc: Marcel Moolenaar , Phil Shafer , John-Mark Gurney , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , Marcel Moolenaar 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: Fri, 15 Aug 2014 14:45:07 -0000 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 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 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.