From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 15:19:05 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 97D6E9D1; Fri, 15 Aug 2014 15:19:05 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 747872C6F; Fri, 15 Aug 2014 15:19:05 +0000 (UTC) Received: from [10.0.1.20] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id DCA85346DE23; Fri, 15 Aug 2014 08:19:04 -0700 (PDT) Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alfred Perlstein In-Reply-To: Date: Fri, 15 Aug 2014 08:19:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D4EDA4C-6D60-4D05-A1BD-44121EF020B5@mu.org> References: <201408131936.s7DJaA1r089174@idle.juniper.net> <20140814052648.GM2737@kib.kiev.ua> <16CE0543-0616-415D-9E68-EEB053DE4254@xcllnt.net> <20140815082501.GR2737@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1283) 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 15:19:05 -0000 On Aug 15, 2014, at 7:44 AM, Alfred Perlstein wrote: > Agree with kib.=20 >=20 > Kib, one thing that I just don't understand is the point of even being = able to query programs for libxo support. Does it make sense to you? =20 I guess one other thing I should mention is that I understand the point = of querying programs for support, but just not in this case. An example where this would make more sense would be for instance for = binaries that can run as a process thread without global state. An example of this would be a version of ls(1) or even awk(1) that = instead of the shell doing a fork/exec for a pipeline, it would note = that the program supports "threaded mode" and instead dlopen the program = and call a special function to run this former subprocess as a thread. This would reduce IPC cost and cost of fork/exec. In that case one = makes the assumption that if the program is somehow tagged then it can = be run as a thread regardless of command line args. However in the case of formatted output=85 I just don't see the need. Can someone explain an actual use case here that makes sense? -Alfred >=20 > Sent from my iPhone >=20 >> On Aug 15, 2014, at 1:25 AM, Konstantin Belousov = wrote: >>=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 = wrote: >>>>>=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 = 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 >>> 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. > _______________________________________________ > 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" >=20