On 11-Feb-2016 09:55 PM, H.J. Lu wrote:
On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde
<hegdesmail...@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
<hegdesmail...@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.
(I suddenly see the subject changed to gnu-gabi from linux-abi. If I
missed any e-mail in the transition, my apologies.)
Why should it re-describe or repeat what already exists in LSB. For
instance, the Exception Handling Framework?
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
I understand that the forum (an exclusive gABI discussion group) is not
there in LSB. That matches with what you have created. But the resulting
standards document is already there in LSB.
Am I missing anything very obvious?
On 11-Feb-2016 10:08 PM, Joseph Myers wrote:
I think that none of the ABI extensions in question are anything to do
with Linux, the kernel. Rather, they are ABI extensions for userspace in
the GNU system, which apply the same under multiple kernels (but some of
them may well not apply to Android systems using the Linux kernel, for
example, if the Bionic C library and dynamic linker lack the relevant
features). Thus it would be more appropriate for a mailing list to be
hosted on sourceware or Savannah, and for any resulting documents to refer
to GNU, not to Linux.
These points look very logical. Even I would like to agree to it, but
after clearing some of the conflicting points I have.
1. The LinuxFoundation.Org and hence the "Linux" Standard Base has been
created for "Linux, the platform" and not "Linux, the kernel". Am I
right? If I am right, why not make ourse;ves part of the foundation and
hence standards? Its one big central place.
2. As I know, and also as H.J. mentioned, some of the extensions may
involve the kernel eventually. Those may not be immediately under
discussion in this thread. Even I have a couple of things (regarding
non-volatile memory or special memory area) and it may involves kernel.
But these may not be yet mature for a wider-audience discussion. But
targeted for "Linux, the platform".
On 11-Feb-2016 11:50 PM, Mark Wielaard wrote:
I am not a big fan of google groups mailinglists, they seem
to make it hard to subscribe and don't have easy to access archives.
Having a local gnu-gabi group on sourceware.org would be better IMHO.
The x32, x86-64, IA-64, IA-32, SYS-V gABI, are all on google groups. Am
I right? If I am right, then this Linux-ABI also looks good uder google
groups I think. But this can be anything. Not of a major concern I believe.
Based on my understanding, to summarize: Discussions or groups can be
anywhere. But the resulting standards/documents should be part of LSB.
Is there any conflict?
--
Supra
