This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
H.J. Lu wrote:
On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde <hegdesmailbox@gmail.com> wrote:On 11-Feb-2016 07:21 PM, H.J. Lu wrote:On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde <hegdesmailbox@gmail.com> wrote:H.J, I think we are fragmenting with too many standards and mailing lists. This new discussion group and eventually the resulting standards, all might be put under LSB http://refspecs.linuxfoundation.org/lsb.shtml The Intro on LSB says: http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html And thats what this proposal is intended for. And we can use the LSB mailing list https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all discussions. What do you think?LSB lists extensions which have been implemented. But it isn't a spec you can use to implement them. For example: http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO. But it gives no details. Linux ABI group is the place where we propose extensions before they get implemented.How to implement, according to me, is design details of a particular product. It also depends on the language used to develop the product. Standards, in most cases, are not tied to a language and hence do not enforce implementation details.That is exactly what Linux ABI group tries to address. Please see the Linux gABI extension draft at https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI It describes the conventions and constraints on the implementa- tion of these extensions for interoperability between various tools.
Intel ABI allows abi for binary compatibility on intel machines - just copy bins no need to target compile.
Linux ABI? linus already suggested this in even 1990's releases: warning: do not share your kernel headers with applications, they might abuse it and anyway software relying on it would break soon (be a waste of time) when new releases released
i just noticed myself the BEST PROTECTION against the need of ABI: is a kernel that has abi inside and offers fast exported features on "well known unix interfaces" to what otherwise would make software "machine dependant, fallible, and short lived"
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |