Date: Sat, 3 Jan 2004 02:07:26 +0100
From: Andi Kleen <ak@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: joe.korty@ccur.com, akpm@osdl.org, torvalds@osdl.org,
       linux-kernel@vger.kernel.org, albert.cahalan@ccur.com,
       jim.houston@ccur.com
Subject: Re: siginfo_t fracturing, especially for 64/32-bit compatibility
 mode
Message-Id: <20040103020726.7c4397bc.ak@suse.de>
In-Reply-To: <20040103004406.GA24876@devserv.devel.redhat.com>
References: <20040102194909.GA2990@rudolph.ccur.com>
	<20040103012433.6aa4cafb.ak@suse.de>
	<20040103004406.GA24876@devserv.devel.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1234
Lines: 35

On Fri, 2 Jan 2004 19:44:06 -0500
Jakub Jelinek <jakub@redhat.com> wrote:

> On Sat, Jan 03, 2004 at 01:24:33AM +0100, Andi Kleen wrote:
> > > rt_sigqueueinfo(2) subverts this by reserving a range of si_code
> > > values for users, and there is nothing about them to indicate to the
> > > kernel which fields of siginfo_t are actually in use.  This is not a
> > 
> > My understanding was that the syscall always only supports si_int/si_ptr.
> 
> No, why?

Because otherwise it cannot be supported in the 32bit emulation. Or rather you
won't get any conversion.

> 
> > > 
> > > The current conflicts are:
> > 
> > [...SI_TKILL, SI_ASYNCIO...] that's broken. We just cannot support that. This aspect of 
> > SuS just cannot be emulated in user space, glibc was misguided about attempting
> > it.
> 
> SI_ASYNCNL is -60, not -6.
> Negative si_code values are reserved for userspace, while positive ones are for
> kernel space.

Ok, if the kernel generates that that's broken too then.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/