This is the mail archive of the libc-alpha@sourceware.cygnus.com 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]

Re: Fix struct siginfo


Jes:

> Chris> On the bright side, if we change it now, every program using
> Chris> glibc will work properly on i386, there will be less overhead
> Chris> in the signal code (good because real-time signals should be
> Chris> FAST), and the only platform that will require recompiles is
> Chris> m68k.
> 
> Which is not like a new platform.
> 
> I am overly behind on the m68k at the moment, so I am not quite sure
> of the impact of this, but if you end up breaking normal signal
> handling on the m68k I must admit I am going to get more than a little
> pissy ;-)

I should have apologized for writing that :)
I didn't mean to marginalize m68k, I have a few Amigas at home and one of
these days I am going to get around to installing Linux on them :)

Basically, i386 and m68k have been using a broken glibc for a while now,
and any program that tries to get a uid out of a siginfo structure will
get nonsense values on many 2.2 kernels. On more recent 2.3 and 2.4
kernels, they may get non-garbage uid values.

The proposed change is to modify Linux 2.3 so that the kernel siginfo
structure matches the glibc one. On i386, this will have the following
effect:

	old 2.2 kernels: 	glibc 2.1 programs get nonsense uids in siginfo
				non-glibc programs get correct uids
				glibc 2.2 programs get nonsense uids

	recent 2.2 kernels:	glibc 2.1 programs get correct uids in siginfo
				non-glibc programs get correct uids
				glibc 2.2 programs get correct uids

	2.3/2.4 kernels		glibc 2.1 programs get correct 32-bit uids
				non-glibc programs get correct uids
				glibc 2.2 programs get correct 32-bit uids

If we were to make the same change to m68k, it would have this result:

	all 2.2/2.3 kernels:	glibc 2.1 programs get nonsense uids in siginfo
				non-glibc programs get correct uids
				glibc 2.2 programs get nonsense uids

	2.3 kernels w/change:	glibc 2.1 programs get correct 32-bit uids in siginfo
				non-glibc programs get nonsense uids
				glibc 2.2 programs get correct 32-bit uids


The alternative is to introduce a new field structure on m68k that stores
a 32-bit UID, while preserving the existing one. This would have the
following result:

	all 2.2/2.3 kernels:	glibc 2.1 programs get nonsense uids in siginfo
				non-glibc programs get correct uids
				glibc 2.2 programs get nonsense uids

	2.3 kernels w/change:	glibc 2.1 programs get nonsense uids in siginfo
				non-glibc programs get correct uids
				glibc 2.2 programs get correct 32-bit uids


The unfortunate part is that it's not going to be very easy or practical
to do "perfect backwards compatibility" here. However, since only glibc
2.1 includes the library calls to do rt signals, and since glibc 2.1 has
always been broken, it may not be too bad to break things now.

The question is: is anyone using the uid field of the siginfo structure on
		 m68k and NOT using glibc 2.1?

Thanks,

Chris Wing
wingc@engin.umich.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]