On Mon, Jan 14, 2019 at 03:21:04PM +0100, Greg Kroah-Hartman wrote: > On Fri, Jan 04, 2019 at 02:44:49PM +0100, David Sterba wrote: > > On Fri, Jan 04, 2019 at 02:25:20PM +0100, Greg Kroah-Hartman wrote: > > > When calling debugfs functions, there is no need to ever check the > > > return value. The function can work or not, but the code logic should > > > never do something different based on this. > > > > > > Cc: Chris Mason <[email protected]> > > > Cc: Josef Bacik <[email protected]> > > > Cc: David Sterba <[email protected]> > > > Cc: [email protected] > > > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > > --- > > > fs/btrfs/sysfs.c | 10 ++-------- > > > 1 file changed, 2 insertions(+), 8 deletions(-) > > > > > > Meta-comment, why is there a btrfs debugfs directory at all? All you > > > have here is a single "test" file that doesn't do anything except expose > > > a variable that never changes. What is this directory and single file > > > for? Can I just delete the whole thing? > > > > As explained in the commit that introduces the function > > (1bae30982bc86ab66d61ccb): > > > > Help during debugging to export various interesting infromation and > > tunables without the need of extra mount options or ioctls. > > > > Usage: > > * declare your variable in sysfs.h, and include where you need it > > * define the variable in sysfs.c and make it visible via > > debugfs_create_TYPE > > > > Depends on CONFIG_DEBUG_FS. > > > > It's there for developers, so don't delete it. Which also means the > > error code should be handled and not ignored. > > If no one has used it, why keep it?
That no one can tell for sure, we don't get notified. I know that implementing the debugfs support was not all trivial and saved time. If this savs time to other developers, why delete it? > Anyway, if you want it there, that's fine, but no, the error message can > be ignored. You should never have a different code flow if a debugfs > call fails or not. So the patch I posted here is still correct and > should be applied. I disagree with that. The usecase is for devleopers, who intentionally add own debugging information. It does not mean the code changes gets committed in the end, but the debugfs infrastructure is used and should work reliably at this point. This means that either the data get exported or there's an early exit when something goes wrong. Silent failure in this case can waste hours of testing or debugging. I fail to see your logic to never rely on debugfs calls success/failure. Debugfs is a tool like any other, with narrow group of users and usecases but can be valuable. If you need to extend return values or do other cleanups, then fine, but I'm not going to apply the patch in its current form as it would harm my own usecase, sorry. > > I can enhance the comment so it's explained in-place and not too > > tempting to remove it. This is not the first time somebody wants to > > remove it > > (https://lore.kernel.org/linux-btrfs/[email protected]/), > > If it keeps wanting to get removed, that's a big hint maybe you should :) If there's a good explanation why it should be removed, then yes. If there's a reason to keep it, then no. So far I've seen drive-by attempts to remove some seemingly unused code by people who don't work in the area of the subsystem and may not understand its purpose.
