Re: [PATCH 5/5] sound: soc: core: no need to check return value of debugfs_create functions

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2470 bytes --]

On Fri, Jun 14, 2019 at 06:13:39PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 04:34:05PM +0100, Mark Brown wrote:
> > On Fri, Jun 14, 2019 at 11:47:56AM +0200, Greg Kroah-Hartman wrote:

> > The majority of this is removing error prints rather than code that
> > actively does something different.  If this was like kmalloc() where the
> > API is itself reported errors then this wouldn't be an issue but unless

> No, the long-term goal is for debugfs_create_file() to just return void.
> I have already done enough cleanups in my local tree to do that already
> for many of the helper functions.

> No one should care one bit if a debugfs file succeeds or not, no logic
> should ever change, nor should it matter.  debugfs is for debugging
> kernel code, not for anything that anyone should ever rely on.

I don't think this would be a helpful change.  Nobody should care about
debugfs file creation for *production* use but that doesn't mean that
people using it for debugging shouldn't care about it.  Debugging tools
that are fragile can be very misleading for developers and hence
intensely frustrating; it's never fun to be building on quicksand.  This
is particularly true for code like here where the core is providing a
bunch of internal data that is hopefully useful to people developing
drivers or system integrations, the users have a hopefully more black
box view of the core than someone directly working on the core would.
If that view of the data ends up being corrupted because some of the
files or directories don't get created that is something we should be
flagging up to people to try to help them avoid being mislead by what
they are seeing.  Developers need to be able to trust their debugging
tools.

> So yes, this patch does remove a bunch of error messages (that as you
> point out can never be triggered), but the main goal here is to not
> check the return value of the function at all, which is what this patch
> does.

Like I said in reply to the other patch the error checking here did the
right thing up until January when debugfs was changed to return error
pointers instead of NULL.  I know that I've found this error checking to
be helpful in the past, not having it would be a loss.  

If there were some visible error reporting in debugfs I'd not be
bothered about this quite so much (though it'd still be less clear) but
there isn't so it really feels like a step back.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]