On Tue, Sep 19, 2023 at 2:22 PM Max Kellermann <max.kellermann@xxxxxxxxx> wrote: > > On Tue, Sep 19, 2023 at 12:59 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > Any API complexity can be hidden from users with userspace > > libraries. You can use the inotify-tools lib if you prefer. > > That doesn't convince me at all, but that's a question of taste. We'll > just keep using inotify (with a patched kernel, which we have anyway). > ok. > > > Getting an already-opened file descriptor, or just the file_handle, is > > > certainly an interesting fanotify feature. But that could have easily > > > been added to inotify with a new "mask" flag for the > > > inotify_add_watch() function. > > > > > > > "could have easily been added" is not a statement that I am willing > > to accept. > > Are you willing to take a bet? I come up with a patch for implementing > this for inotify, let's say within a week, and you agree to merge it? > > (I'm not interested in this feature, I won't ever use it - all I > wanted is dfd support for inotify_add_watch()). > I am not into ego fights. I have no desire to win an argument. If you have an improvement that you want to make, you can submit it and it will be judged technically. If you want to improve inotify you can argue your case and it will be judged technically. But if you do that, I strongly advise to share the community early in the design review of the new feature/API. It can save you time. > > The things that you are complaining about in the API are the exact > > things that were needed to make the advanced features work. > > Not exactly - I complain that fanotify makes the complexity mandatory, > the complexity is the baseline of the API. It would have been possible > to design an API that is simple for 99% of all users, as simple as > inotify; and only those who need the advanced features get the > complexity as an option. > > I don't agree with your point that unnecessary complexity should be > mitigated by throwing more (library) code at it. That's just adding > more complexity and more overhead, the opposite of what I want. > Sorry, "what I want" is not a technical argument :) "what many users want" with proof could be a start of a technical argument. I agree that simplicity of the kernel UAPI vs. delegating simplicity to user libraries is a matter of taste and different subsystem maintainers have different opinions in that regard. And also, it is a bit late to discuss design preferences of an API that was merged 4 years ago. Design flaws and problems, sure, but for complexity it's a bit late. Regarding inotify improvements, as I wrote, they will each be judged technically, but the trend is towards phasing it out. Thanks, Amir.
