Date: Fri, 15 Aug 2014 08:19:12 -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: <3D4EDA4C-6D60-4D05-A1BD-44121EF020B5@mu.org> In-Reply-To: <D0921A8C-2D3B-4C9F-BB55-6C028F449DE5@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> <D0921A8C-2D3B-4C9F-BB55-6C028F449DE5@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 = <kostikbel@gmail.com> 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 = <kostikbel@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D4EDA4C-6D60-4D05-A1BD-44121EF020B5>