* Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Mar 7, 2017 at 3:33 PM, Linus Torvalds > <torva...@linux-foundation.org> wrote: > > > > But as mentioned - this is untested. It seems to build, and it looks > > "ObviouslyCorrect(tm)", but I didn't actually try to boot it. > > Well, it boots, but it's not like there are all that many users of the > wait_event_interruptible*_locked*() interfaces, so it's dubious that I > actually exercised the changes all that much (if at all). > > Of course, that's just more reason to *not* have it be some big macro > expansion in a header file that requires other includes. Basically, > this interface isn't worth the header inclusion pain. > > And no, I didn't try to see how many > > #include <linux/sched/signal.h> > > I could try to remove with this. > > But I *did* verify that I could now build that fs/overlayfs/util.c > file with that #include removed. > > That's the case that caused a semantic merge issue for me - but I > don't know how many others Ingo added as part of the split-up.
I suspect wait_event_hrtimeout*() has a similar conceptual problem with linux/hrtimer.h, because it uses hrtimer APIs but doesn't include the header - but fortunately that API variant does not appear to be used much at the moment: only fs/aio.c uses wait_event_interruptible_hrtimeout(), but it includes sched.h which includes hrtimer.h. So Ack on your patch. Also, to be honest I'm also not looking forward to converting 20+ wait_event*() macros to a fragile state machine, so I wouldn't mind it if your patch was the final solution to this problem! ;-) Thanks, Ingo