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

[Konstantin Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140815/18c1f535/attachment.sig>