All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@baldric.uwo.ca>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Randolph Chung <randolph@tausq.org>, parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] what's up with the ipc syscalls?
Date: Mon, 3 Nov 2003 16:41:19 -0500	[thread overview]
Message-ID: <20031103214119.GD778@systemhalted> (raw)
In-Reply-To: <20031103085601.GA9083@solo.franken.de>

On Mon, Nov 03, 2003 at 09:56:01AM +0100, Thomas Bogendoerfer wrote:
> glibc 2.2.x, some weeks before woody went final. For a closer date
> check the date of my sys_parisc.c commit.

My apologies Thomas I think I begin to see your logic. Now if you follow
me I'll paint a picture.

a. We don't have an IPC multiplexor.
b. We added all such functions into syscalls.list so they would be
   generated as assembly wrappers.
c. Kernel would activate IPC64 for all the calls so it returned IPC64 to
   userspace.

> Since there might be still binaries in woody, which are compiled
> with an such an "old" glibc, we will break this binaries. The suggested
> change is an change of the kernel ABI, so I would avoid it. The problem
> with this "old" glibc was, that the structs for shmctl and friends
> weren't properly aligned for 64bit. I've changed that and also decided
> to get rid of IPC_64, because that's x86 crap.
> 
> Adding the 2.4 changes to the 2.6 kernel should fix everything.

Should an old binary exist with this old glibc, it would break should
the kernel stop activating IPC64.

I agree that the 2.4 changes forward ported will change everything, but
the glibc changes are *also* required so we can eventually turn off the
kernel code that activates IPC64 for all the incoming calls. When we
don't care about these old binaries and old glibc we will remove the
kernel code.

Now it's my turn to ask the question: Did that make any sense? :o)

c.

  reply	other threads:[~2003-11-03 21:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-01  8:24 [parisc-linux] what's up with the ipc syscalls? Randolph Chung
2003-11-02 18:01 ` Thomas Bogendoerfer
2003-11-02 18:12   ` Randolph Chung
2003-11-02 21:42     ` Thomas Bogendoerfer
2003-11-02 21:55       ` Randolph Chung
2003-11-03  8:59         ` Thomas Bogendoerfer
2003-11-02 22:56       ` Carlos O'Donell
2003-11-03  8:56         ` Thomas Bogendoerfer
2003-11-03 21:41           ` Carlos O'Donell [this message]
2003-11-10 23:44             ` Thomas Bogendoerfer
2003-11-11 20:41               ` Joel Soete
2003-11-11 21:46               ` Carlos O'Donell
2003-11-12 15:32                 ` Thomas Bogendoerfer
2003-11-14  0:35                   ` Carlos O'Donell
2003-11-12 19:54                 ` JSO

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031103214119.GD778@systemhalted \
    --to=carlos@baldric.uwo.ca \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=randolph@tausq.org \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.