On Tue, Oct 2, 2018 at 12:30 PM Jan Kara <jack@xxxxxxx> wrote: > > On Thu 27-09-18 22:32:23, Amir Goldstein wrote: [...] > > - I do not like the idea of changing uapi bit group constants > > (FAN_ALL_INIT_FLAGS) and adding new bit group constants > > (FAN_EVENT_INFO_FLAGS) which I don't think should be in uapi. > > I agree on the "should not be in uapi" part. For FAN_ALL_INIT_FLAGS > changing the constant is IMO no real issue as I just cannot imagine how > anybody could use that. For FAN_EVENT_INFO_FLAGS the concern is real, I > agree. I agree that changing FAN_ALL_INIT_FLAGS is a non issue, but since I made a change called "fanotify: deprecate uapi FAN_ALL_* constants" I saw no reason to exclude it. Same goes for FAN_ALL_MARK_FLAGS and FAN_ALL_CLASS_BITS... Also, since FAN_EVENT_INFO_FLAGS is defined outside uapi header and FAN_ALL_INIT_FLAGS needs to include FAN_EVENT_INFO_FLAGS I needed to use a constant FAN_ALL_USER_FLAGS that is also defined outside uapi header. > > > - uapi flag FAN_MARK_FILESYSTEM collides with kernel internal flag > > FAN_MARK_ONDIR > > Good point, that needs to be fixed. Probably we miss some bit in the > BUILD_BUG_ON tests... Looking at FAN_MARK_ONDIR I just don't see why that > is needed at all but let's leave that for a future cleanup. > I have added that missing BUILD_BUG_ON in the posted RFC. Now with the user/kernel flags split, it looks conveniently like this: BUILD_BUG_ON(FAN_USER_MARK_FLAGS & FAN_KERN_MARK_FLAGS) Thanks, Amir. > > Sigh! > > I will send a suggestion patch of how I think those issues should be sorted > > out as a basis for making the API change for_next safer. > > OK, I'll have a look at your patch and decide how to go about it. > > Honza > -- > Jan Kara <jack@xxxxxxxx> > SUSE Labs, CR
