lkml.org 
[lkml]   [2000]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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


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

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:3.875 / U:0.360 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site