Messages in this thread | | | Subject | Re: [PATCH] signalfd: fill in ssi_int for posix timers and message queues | From | Nathan Lynch <> | Date | Wed, 21 Jul 2010 12:39:37 -0500 |
| |
On Tue, 2010-07-20 at 21:10 -0700, Andrew Morton wrote: > On Tue, 20 Jul 2010 22:44:19 -0500 Nathan Lynch <ntl@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)
| |