make AT_SYSINFO platform-independent

make AT_SYSINFO platform-independent

Post by David Mosberge » Sun, 12 Jan 2003 08:50:05



How about moving the AT_SYSINFO macro from asm-i386/elf.h to
linux/elf.h?  Several architectures can benefit from it (certainly
pa-risc and ia64) and since glibc also defines it in a
non-platformspecific fashion, there really is no point not doing the
same in the kernel.  I suppose it would be nice if we could renumber
it from 32 to 18, but that would require updating glibc, which is
probably too painful.

        --david

===== include/asm-i386/elf.h 1.5 vs edited =====
--- 1.5/include/asm-i386/elf.h  Thu Jan  2 07:22:48 2003

 #define ELF_PLATFORM  (system_utsname.machine)

-/*
- * Architecture-neutral AT_ values in 0-17, leave some room
- * for more of them, start the x86-specific ones at 32.
- */
-#define AT_SYSINFO     32
-
 #ifdef __KERNEL__
 #define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)

===== include/linux/elf.h 1.16 vs edited =====
--- 1.16/include/linux/elf.h    Thu Dec 26 14:07:53 2002

 #define AT_PLATFORM 15  /* string identifying CPU for optimizations */
 #define AT_HWCAP  16    /* arch dependent hints at CPU capabilities */
 #define AT_CLKTCK 17   /* frequency at which times() increments */
+#define AT_SYSINFO     32      /* pointer to kernel's sysinfo */

 typedef struct dynamic{
   Elf32_Sword d_tag;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Christoph Hellwi » Sun, 12 Jan 2003 13:10:10



> How about moving the AT_SYSINFO macro from asm-i386/elf.h to
> linux/elf.h?  Several architectures can benefit from it (certainly
> pa-risc and ia64) and since glibc also defines it in a
> non-platformspecific fashion, there really is no point not doing the
> same in the kernel.  I suppose it would be nice if we could renumber
> it from 32 to 18, but that would require updating glibc, which is
> probably too painful.

I think it should be updated.  There is no released glibc or stable kernel
with that number yet.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Linus Torvald » Sun, 12 Jan 2003 21:00:06




> > How about moving the AT_SYSINFO macro from asm-i386/elf.h to
> > linux/elf.h?  Several architectures can benefit from it (certainly
> > pa-risc and ia64) and since glibc also defines it in a
> > non-platformspecific fashion, there really is no point not doing the
> > same in the kernel.  I suppose it would be nice if we could renumber
> > it from 32 to 18, but that would require updating glibc, which is
> > probably too painful.

> I think it should be updated.  There is no released glibc or stable kernel
> with that number yet.

Sounds like an uncommonly bad idea to me, since the range 19-22 is already
used at least by PPC.

Yeah, 18 itself may be free (although I wonder _why_? Maybe it's some old
value that is no longer used by the kernel but old binaries may know
about?) but the fact is that there just isn't room in the low numbers,
which was why I put it up higher.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Ulrich Dreppe » Sun, 12 Jan 2003 21:00:12



> I think it should be updated.  There is no released glibc or stable kernel
> with that number yet.

Actually, we've included the support already in some published code.  If
you want to complain to somebody about this, do it to the person who is
responsible for distributing this code.  His email address is


Make sure you react with the same nastiness as if I would have made the
decision, OK?

--
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Christoph Hellwi » Sun, 12 Jan 2003 21:00:18




> > I think it should be updated.  There is no released glibc or stable kernel
> > with that number yet.

> Actually, we've included the support already in some published code.  If
> you want to complain to somebody about this, do it to the person who is
> responsible for distributing this code.  His email address is


> Make sure you react with the same nastiness as if I would have made the
> decision, OK?

-EWHATSUP

Who is we?  And why should I care who selected that number.  There is no
glibc release yet and no stable kernel release yet with that number.
Interfaces change during 2.5 (see the sys_security and largepage syscall
removal) and that's okay.  There was no nastiness involved in my
suggestion.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Ulrich Dreppe » Sun, 12 Jan 2003 21:10:08



> Who is we?  And why should I care who selected that number.

It's not about who selected the number, it's about who's responsible for
distributing binaries which use the currently used number.

Quote:> There is no
> glibc release yet and no stable kernel release yet with that number.

Of course there is.  You better don't talk about thinks you don't know.

Quote:> Interfaces change during 2.5 (see the sys_security and largepage syscall
> removal) and that's okay.  There was no nastiness involved in my
> suggestion.

You don't get it.  I would never have distributed binaries with the
current code if it wouldn't have been requested along with the guarantee
that the current interface is stable and final.

--
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Christoph Hellwi » Sun, 12 Jan 2003 21:20:08



> > glibc release yet and no stable kernel release yet with that number.

> Of course there is.  You better don't talk about thinks you don't know.

The latest glibc release, 2.3.1 does not contain AT_SYSINFO support.
I might be not as briliant as you but I'm certainly not stupid.

Quote:> > Interfaces change during 2.5 (see the sys_security and largepage syscall
> > removal) and that's okay.  There was no nastiness involved in my
> > suggestion.

> You don't get it.  I would never have distributed binaries with the
> current code if it wouldn't have been requested along with the guarantee
> that the current interface is stable and final.

Sorry, but having not yet fixed interfaces is the whole point of
development kernels.  If vendors can't resist using the latest and gratest
features they get screwed.  RH seems to have the manpower to maintain their
mistakes for a long enough time, so what's the issue?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Ulrich Dreppe » Sun, 12 Jan 2003 21:30:10



> If vendors can't resist using the latest and gratest
> features they get screwed.

You still don't get it.  RH hasn't added the support to binaries we ship
because we wanted or needed it but instead because Linus requested it.
I see no reason to not believe Linus when he says an interface is
stable.  And that's exactly what he said (or wrote in this case).

--
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Christoph Hellwi » Sun, 12 Jan 2003 21:40:06



> I see no reason to not believe Linus when he says an interface is
> stable.  And that's exactly what he said (or wrote in this case).

Linus had no problem with changing his opinion after strong words in the
past :)

But what exactly is the problem with a changing defintion for you.  There
is neither a stable kernel nor a formal glibc release with this defined
out yet.  That means the ABI isn't formalized and the number can be
allocated where it belongs.

Who cares what Linus said in the past as long as Linux development goes
to the right direction?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Linus Torvald » Sun, 12 Jan 2003 21:40:08



> -EWHATSUP

Ehh, Uli is a bit sensitive, and thinks everybody blames him for
everything. I told him the AT_SYSINFO interface is stable, so he wants to
make it clear that _I_ am the one to blame, not him.

Anyway, as I said in another mail, I think 18 is a bad choice, and I'll
leave it at 32.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by David Mosberge » Sun, 12 Jan 2003 21:40:10


  Linus> Anyway, as I said in another mail, I think 18 is a bad
  Linus> choice, and I'll leave it at 32.

But you will move it into <linux/elf.h>?

        --david
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Christoph Hellwi » Sun, 12 Jan 2003 21:40:09




> > -EWHATSUP

> Ehh, Uli is a bit sensitive, and thinks everybody blames him for
> everything. I told him the AT_SYSINFO interface is stable, so he wants to
> make it clear that _I_ am the one to blame, not him.

Oh, I have absolutely no problem to blame you 8)

Quote:> Anyway, as I said in another mail, I think 18 is a bad choice, and I'll
> leave it at 32.

But please at least fixup the comment that talks about x86-specific entries
starting at 32 then.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Alan Co » Mon, 13 Jan 2003 01:40:08



> > Actually, we've included the support already in some published code.  If
> > you want to complain to somebody about this, do it to the person who is
> > responsible for distributing this code.  His email address is


> > Make sure you react with the same nastiness as if I would have made the
> > decision, OK?

> -EWHATSUP

> Who is we?  And why should I care who selected that number.  There is no

Linus promised it was stable.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

make AT_SYSINFO platform-independent

Post by Jeff Garzi » Mon, 13 Jan 2003 01:50:10



> Linus promised it was stable.

Sort of like 2.4.0?

Oh sorry.  I really couldn't resist.  ;-)

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Best windows (platform-independent) Debugger?


What's currently the best debugger available. GNU?
I'm new to UNIX and looking for something which will run across
 several platforms - Ultrix, SUN, Apollo, etc - in a windows environment
 using C, FORTRAN, etc.
Price is a major consider - public domain is most attractive.
Thanks in advance,
John

                            +-------------------+
                            |   ( )       ( )   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name           : John B. Macallister                                        |
| Postal address : Nuclear Physics Laboratory, Keble Road, Oxford OX1 3RH, UK.|
| Telephone      : +44-865-273388 (direct) +44-865-273333 (tel receoption)    |
| Telex          : 83295 NUCLOX G                                             |
| Fax            : +44-865-273418                                             |

|                : UK.AC.OX.PH is DTE 000050250060 on the UK JANET network    |
|                : UK.AC.OX.PH is DTE 204334505211 on IXI                     |


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2. Setting up a Linux ISP

3. Platform-independent shell scripts?

4. Anyone using x8514 and xdm?

5. Platform-independent MAKE

6. named syntax errors

7. ANNOUNCE: Spectrum Software Launches First Truly Integrated, Platform-Independent SCM System In Europe

8. Solaris 2.6 and Apache 1.2.6 access problem

9. platform independent installation tools

10. No fast platform independent interfaces?

11. Are IEEE floats platform independent?

12. Platform independent JavaScript engine server application.

13. Platform independent IPsec