XML Output: libxo - provide single API to output TXT, XML, JSON and HTML

[Alfred Perlstein]

On Aug 15, 2014, at 7:44 AM, Alfred Perlstein wrote:

> Agree with kib. 
> 
> 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?  

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… I just don't see the need.

Can someone explain an actual use case here that makes sense?

-Alfred


> 
> Sent from my iPhone
> 
>> On Aug 15, 2014, at 1:25 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
>> 
>>> On Thu, Aug 14, 2014 at 10:04:36AM -0700, Marcel Moolenaar wrote:
>>> 
>>> On Aug 13, 2014, at 10:26 PM, Konstantin Belousov <kostikbel at gmail.com> wrote:
>>>>> 
>>>>> 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.
>>> 
>>> Too extreme.
>>> 
>>>>> 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.
>>> 
>>> 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 ?
>> 
>>> 
>>>> 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 ?
>>> 
>>> 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.
>> 
>>> 
>>> 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.
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>