On Sat, 22 Jun 2019 21:57:07 +0200, Cezary Rojewski wrote:
On 2019-06-14 11:47, 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.
This change heavily impacts user space and development kits used by us internally, and our clients. That is, if anything goes wrong during debugfs initialization process.
Currently, apps may safely assume entire debugfs tree is up and running once audio stack gets enumerated successfully. With your patch this is no longer the case and user space is forced to verify status of all debugfs files and/ or directories manually.
Most of this you knew already - I see Mark was very vocal about consequences and possible regression. Nonetheless we have had a short meeting with our coe-audio members regarding this change, specifically. Conclusion was simple: losing ability to test debugfs objects status during their creation e.g.: via IS_ERR family is considered harmful.
Well, I just wonder whether you have ever seen a case where the debugfs creation failed. Or more practically, would it fail silently at all?
If there can be a silent failure, then it's bad to just ignore, yes. We may need either to make it more obvious or return an error.
Of course, in a tight memory pressure, the creation may fail; but the whole system won't work properly in anyway (not only that the clear error would be shown in kernel messages), so relying on the debugfs itself make little sense in such a situation.
thanks,
Takashi