Date: Thu, 14 Aug 2014 00:52:11 -0400 From: Phil Shafer <phil@juniper.net> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Marcel Moolenaar <marcel@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <201408140452.s7E4qB2X091511@idle.juniper.net> In-Reply-To: <613EB1A5-2932-446A-A9A2-8CBDD060A00B@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar writes:
>Using environment variables can be handy, but isn't always.
Yes, and there's a flag to turn this behaviour off (XOF_NO_ENV).
An app that doesn't want this can turn it off at the top of
main() using:
xo_set_flags(NULL, XOF_NO_ENV);
Also, the variable only affects the default handle, not any created
by hand.
>What do you think about calling a libxo init function from
>main() and giving it argc and argv so that libxo options
>are parsed and removed just like what xlib does?
I don't want to presume that libxo's set of options are suitably
distinct to allow safe canibalization of argv.
But I do have a function (xo_set_options) that allows
the app to pass options in opaquely, like:
switch (getopt(..."X:"...)) {
...
case 'X':
if (xo_set_options(NULL, optarg) < 0)
xo_errx(1, "invalid xo option: %s", optarg);
break;
...
But there's a chicken/egg problem, since these options need to be
set before any text or errors are generated to ensure they are
rendered in the right style. Something like:
netstat --bad-option -X json,pretty
wouldn't be making pretty json.
Even then there could be issues like ld.so loading errors where
having it set before loading begins makes sense (assuming ld.so
gets munged to use libxo).
>A note section is definitely possible and reasonable.
>Especially if it's a note section for listing features. A
>special utility that consumes the note section to list
>features and returns whether a feature is supported is then
>very reasonable because it's generic. libxo would be the
>first feature we can check for.
Cool. I'll give it a try.
>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?
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. 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.
>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? 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"?
>The last suggestion has some issues
>with handling the behaviour when libxo isn't supported
>therefore, a passive way to check seems better than having
>to run the utility.
I'd prefer a scheme where I can know before I run it what's needed.
If the notes scheme is used generically, I could conceivably look
further down the $PATH for a binary that supports my needs.
Hmmm.... that would be a way to address the need to add an arch-based
component to my $PATH in a scenario when $HOME is nfs mounted on
machines with different architectures.
>BTW: this is pretty powerful stuff! I feel FreeBSD is
>maturing :-)
Thanks. I need all the encouragement I can get; netstat alone has
~500 printf calls, many of which have me grepping kernel sources
to determing sane field names.
Thanks,
Phil
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408140452.s7E4qB2X091511>