Linus Torvalds Rejects Eventfs Garbage

Steven, stop making things more complicated than they need to be. And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap. The whole "get_next_ino()" should be "atomic64_add_return()". End of story. You arent' special. If the VFS functions don't work for you, you don't use them, but damn it, you also don't then steal them without understanding what they do, and why they were necessary. The reason get_next_ino() is critical is because it's used by things like pipes and sockets etc that get created at high rates, the the inode numbers most definitely do not get cached. You copied that function without understanding why it does what it does, and as a result your code IS GARBAGE. AGAIN. Honestly, kill this thing with fire. It was a bad idea. I'm putting my foot down, and you are *NOT* doing unique regular file inode numbers until somebody points to a real problem. Because this whole "I make up problems, and then I write overly complicated crap code to solve them" has to stop,. No more. This stops here. I don't want to see a single eventfs patch that doesn't have a real bug report associated with it. And the next time I see you copying VFS functions (or any other core functions) without understanding what the f*ck they do, and why they do it, I'm going to put you in my spam-filter for a week. I'm done. I'm really *really* tired of having to look at eventfs garbage. Linus

A long monospaced software-development rant addressed to Steven and signed by Linus, criticizing copied VFS functions and overly complicated eventfs code. The joke is the exaggeratedly furious code-review response, used as a reaction to needless overengineering, bad patches, or contributors making simple problems worse.

• @right_wing_dev_squads / 8802 2024-02-24