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

[Marcel Moolenaar]

On Aug 13, 2014, at 9:52 PM, Phil Shafer <phil at juniper.net> wrote:
> 
>> The question is: do we have
>> more features we want to check for this way? If not, then
>> such a scheme could be perceived as "heavy handed".
> 
> "heavy handed" in what sense?

A generic implementation calls for a utility that
can list features, check for a feature, add and
remove features. You probably want to have support
libraries as well to do the same thing from within
C and C++, etc.

If all we're talking about is libxo then there are
surely less work-intensives ways to achive what we
want.

In that sense heavy-handed.

> I'm hoping the note can be added by normal linker magic (but see
> question below).  If not a "noteelf" command would need to be created
> (or an option to brandelf?) to mark the binary.

Ideally, features set in the same way we do for.
the kernel. Only in the kernel it ends up being
a sysctl, which doesn't apply here.

Alternatives in the kernel are linker sets and
I've used those in mkimg as well. A linker set
is like a note, except that the metadata is in
a loadable section and thus part of a loaded
segment. This has the advantage of being able
to go over your own set of features from within
C and C++, etc and it doesn't require a utility
to add and remove features to a set.

Checking for a feature from some other program
is probably as hard as a note, assuming there
was a single note to list all features. In both
cases you first have to find the container with
some ELF grokking utility and then you need to
parse the container's data to find a feature.
A note has the benefit over a section in that
I can make changes without having (effectively)
to relink.




>  Are you seeing
> something more?  "elfdump" has a "-n" to dump notes, and a "-N
> <name>" could be added, making "elfdump -n -N libxo my-app" the
> means of getting the contents.  A "-q" option could be added to
> prevent output but set the exit code based on if the section appears
> in the given binary.

I think I prefer a more intergated solution in
the end. elfdump is that "ELF grokking" utility,
but may not necessarily be appropriate for the
interpretation of the feature set.

But that's for later. For now, something that
works as a prototype is good enough.



> 
>> Alternatives include looking for a particular symbol or
>> possibly even running the utility with a libxo option that
>> has predictable output.
> 
> How does one put a symbol in a binary when linking against a shared
> library?

One doesn't necessarily. A recursive search that
follows the DT_NEEDED could possibly work well
enough. Though, I fear for the likes of Mozilla
that large number of shared libraries. Not that
such is our immediate scope/target, but if there
is an approach that scales well, then that would
be better.


>  Would there need to be two libs, one with the code and
> one with just a symbol?  I'd have the same issue with the ElfNote
> scheme, right?  I'd need to add a section to the binary, but libxo
> could be linked dynamically.  Is there an easy answer for this?  Or
> is the app stuck with "LDADD+=-lxo -lxo-note"?

I don't have a good answer other than that there
isn't a suitable option to LD to leave a turd in
the executable. The absolute easiest is to simply
not support static linking for libxo and then
simply check DT_NEEDED. You can use ldd for that.
That route wouldn't require anything other than
not (ever) building an archive library for libxo.

This is not unreasonable either. The world has
moved away from archive linking for the most part
and while there's still value to static linking,
I see it needed less and less.


-- 
Marcel Moolenaar
marcel at xcllnt.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140814/69742a4a/attachment.sig>