ELF and feature checking [was: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML]

[Marcel Moolenaar]

On Aug 15, 2014, at 1:25 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:

> 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.

I think you'll find that your definition is wrong from the
outset. ELF is also the container for relocatable objects
and intermediate compiler code when doing whole-program
optimizations (i.e. the actual compilation happens at the
link stage). It's also the container for memory snapshot and
core dumps. Neither are actually needed to implement a
runtime system. It's an added application level feature!

ELF explicitly mentions some of those use cases, so it's not
defined for just activation and runtime system.

When a compiler puts intermediate code in an ELF container,
we're already talking about app-level usage. It's been done
for more than 10 years so you're way off in the left field
on this one. Come join us :-)

The reverse is also interest: On amd64 we use relocatable
objects as kernel loadable modules. Heresy!

> - 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.

Sure. But why do you think grocery stores have shelves full
of colored and labeled cans? We do need to be able to see
from the can what it is we're putting in our cart, right?
It would be a real mess if everyone starts opening cans left
and right to find the can with the black beans and not the
kidney beans.

Software isn't that much different that the analogy doesn't
apply. Being able to quick check the container for something
is not unreasonable. Not being able to discuss such an
option because people can't humor each other, is not good
for the project. We'll get to a good solution in the end --
even if it's one you or I don't like. So lighten up.

> - It is unportable.

That's neither here nor there. On the one hand we have
people say that we're over engineering and on the other hand
we have people say that it's not portable. If those people
get a room and make a baby, we'll have the balance we need!
Why are people so afraid to explore? Why do people feel a
need to pull the leash every time a discussion starts to
wander. Innovation is found when the leash is extended and
being pulled on...

We're not looking for a portable solution. We are still
discussing if it's doable or wanted. Portability comes into
play when you have found one or more solutions. Without a
solution portability is like an attribute without an object.

-- 
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/20140815/6aec796c/attachment.sig>