On Sat, 15 Aug 2015 13:26:36 +0600 Alexander Kuleshov <kuleshovm...@gmail.com> wrote:
> Hello Andrew, > > On 08-14-15, Andrew Morton wrote: > > On Sat, 15 Aug 2015 01:03:31 +0600 Alexander Kuleshov > > <kuleshovm...@gmail.com> wrote: > > > > > Signed-off-by: Alexander Kuleshov <kuleshovm...@gmail.com> > > > > There's no changelog. > > Yes, will add it if there will be sense in the patch. > > > > > Why? Ignoring the debugfs API return values is standard practice. > > > > Yes, but I saw many places where this practice is applicable (for example > in the kernel/kprobes and etc.), besides this, the memblock API is used > mostly at early stage, so we will have some output if something going wrong. The debugfs error-handling rules are something Greg cooked up after one too many beers. I've never understood them, but maybe I continue to miss the point. Yes, I agree that if memblock's debugfs_create_file() fails, we want to know about it because something needs fixing. But that's true of all(?) debugfs_create_file callsites, so it's a bit silly to add warnings to them all. Why not put the warning into debugfs_create_file() itself? And add a debugfs_create_file_no_warn() if there are callsites which have reason to go it alone. Or add a debugfs_create_file_warn() wrapper. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
