Little bit unfair as this was already an existing thing that got a new way to be triggered rather than a completely new feature needing code to handle not following symlinks.
To accurately guess you’d need to know that “don’t follow symlinks in this particular scenario” already exists and we’re just adding an OR to an if statement.
Yeah I get that but you dig deeper and that implantation was just throwing an error that needs to be handled elsewhere. The “real” code is what is handling that error.
But then we’re back to act acknowledging a meaningful point of having commits that do one thing and do it well and understandably, and I’m back to appreciating the difference between the kernel and our app.
Little bit unfair as this was already an existing thing that got a new way to be triggered rather than a completely new feature needing code to handle not following symlinks.
To accurately guess you’d need to know that “don’t follow symlinks in this particular scenario” already exists and we’re just adding an OR to an if statement.
You have misunderstood. No, it wasn’t an existing thing. This is the code that implements it. That’s the point.
The change to fs/namei.c is the code to handle not following symlinks; the rest is some necessary code to create the option and expose it to userland.
(Edit: Rereading I do see a little better what you were saying - I actually looked it up and the code that originally implemented not following symlinks, that we’re now adding an or statement to activate, was a 6-line change.)
Yeah I get that but you dig deeper and that implantation was just throwing an error that needs to be handled elsewhere. The “real” code is what is handling that error.
But then we’re back to act acknowledging a meaningful point of having commits that do one thing and do it well and understandably, and I’m back to appreciating the difference between the kernel and our app.