Date: Fri, 15 Aug 2014 08:30:29 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Marcel Moolenaar <marcel@freebsd.org>, Phil Shafer <phil@juniper.net>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net>, arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: ELF and feature checking [was: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML] Message-ID: <247A649F-0195-493A-A668-5D05F0B5100E@xcllnt.net> In-Reply-To: <20140815082501.GR2737@kib.kiev.ua> References: <201408131936.s7DJaA1r089174@idle.juniper.net> <20140814052648.GM2737@kib.kiev.ua> <16CE0543-0616-415D-9E68-EEB053DE4254@xcllnt.net> <20140815082501.GR2737@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_B2A82E7C-1674-4971-8B4D-BDC20FE661A2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Aug 15, 2014, at 1:25 AM, Konstantin Belousov <kostikbel@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@xcllnt.net --Apple-Mail=_B2A82E7C-1674-4971-8B4D-BDC20FE661A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPuJ5UACgkQpgWlLWHuifZVQACfY1BAqCht+n2noZs/6EZyc/LC +FsAnibEOBPh8k4ubQVsV3ZN8KkhIHk8 =HYU3 -----END PGP SIGNATURE----- --Apple-Mail=_B2A82E7C-1674-4971-8B4D-BDC20FE661A2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?247A649F-0195-493A-A668-5D05F0B5100E>