signalfd: fill in ssi_int for posix timers and message queues
in [Kernel]
|
Prev: arch/tile: updates to hardwall code from community feedback.
Next: [PATCH v2] msm: gpio: Add set_wake support to msm7200a-gpio's irq_chip.
From: Andrew Morton on 21 Jul 2010 00:20 On Tue, 20 Jul 2010 22:44:19 -0500 Nathan Lynch <ntl(a)pobox.com> wrote: > > So it's not 100% obvious that this change is desirable. Does the > > functionality which this patch adds justify the introduction of these > > problems? > > I think the change is desirable in that no user of the interface could > reasonably expect the current behavior with respect to the ssi_int > field, and that it reconciles signalfd's behavior with its design > intentions. On the other hand, I noticed this discrepancy only because > I was cribbing signalfd's data structures for checkpoint/restart, not > because I am aware of any application that is affected, nor was I able > to find one using Google's code search. It would be highly speculative > of me to say that no application depends on the current behavior, but it > is difficult to imagine a correctly functioning application that depends > on it. It's not a matter of a current application depending on current behaviour! The problem is that an application written in 2018 which depends on the _new_ behaviour will not work on 2.6.34. It wouldn't be the worst thing we've ever done to our long-suffering users, but it is a permanent cost of having screwed things up :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nathan Lynch on 21 Jul 2010 13:50 On Tue, 2010-07-20 at 21:10 -0700, Andrew Morton wrote: > On Tue, 20 Jul 2010 22:44:19 -0500 Nathan Lynch <ntl(a)pobox.com> wrote: > > > > So it's not 100% obvious that this change is desirable. Does the > > > functionality which this patch adds justify the introduction of these > > > problems? > > > > I think the change is desirable in that no user of the interface could > > reasonably expect the current behavior with respect to the ssi_int > > field, and that it reconciles signalfd's behavior with its design > > intentions. On the other hand, I noticed this discrepancy only because > > I was cribbing signalfd's data structures for checkpoint/restart, not > > because I am aware of any application that is affected, nor was I able > > to find one using Google's code search. It would be highly speculative > > of me to say that no application depends on the current behavior, but it > > is difficult to imagine a correctly functioning application that depends > > on it. > > It's not a matter of a current application depending on current > behaviour! The problem is that an application written in 2018 which > depends on the _new_ behaviour will not work on 2.6.34. Yes, I misinterpreted your concern, sorry. But I've never understood Linux to make promises with respect to forward compatibility at the system call layer. Bug fixes[1] and features[2] that, like this patch, break that compatibility seem to have gone in without raising this issue. Am I mistaken? Or has there been a change in policy I've missed? [1] "signalfd: fix for incorrect SI_QUEUE user data reporting" (0859ab5) [2] "hugetlb: add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions" (4e52780) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Davide Libenzi on 25 Jul 2010 00:20
On Tue, 20 Jul 2010, Andrew Morton wrote: > It's not a matter of a current application depending on current > behaviour! The problem is that an application written in 2018 which > depends on the _new_ behaviour will not work on 2.6.34. > > It wouldn't be the worst thing we've ever done to our long-suffering > users, but it is a permanent cost of having screwed things up :( While I agree it is a problem with the kernel compatibility handling, every time we add new features to an existing interface we end up in similar scenarios. Nowadays a "require kernel >= X.Y.Z" is all but an uncommon case for userspace code. - Davide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |