[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87efibjd5i.fsf@xmission.com>
Date: Wed, 16 May 2018 20:15:21 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Christoph Hellwig <hch@....de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Alexey Dobriyan <adobriyan@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>,
Alessandro Zummo <a.zummo@...ertech.it>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
linux-acpi@...r.kernel.org, drbd-dev@...ts.linbit.com,
linux-ide@...r.kernel.org, netdev@...r.kernel.org,
linux-rtc@...r.kernel.org, megaraidlinux.pdl@...adcom.com,
linux-scsi@...r.kernel.org, devel@...verdev.osuosl.org,
linux-afs@...ts.infradead.org, linux-ext4@...r.kernel.org,
jfs-discussion@...ts.sourceforge.net,
netfilter-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 34/40] atm: simplify procfs code
Christoph Hellwig <hch@....de> writes:
> On Sat, May 05, 2018 at 07:51:18AM -0500, Eric W. Biederman wrote:
>> Christoph Hellwig <hch@....de> writes:
>>
>> > Use remove_proc_subtree to remove the whole subtree on cleanup, and
>> > unwind the registration loop into individual calls. Switch to use
>> > proc_create_seq where applicable.
>>
>> Can you please explain why you are removing the error handling when
>> you are unwinding the registration loop?
>
> Because there is no point in handling these errors. The code work
> perfectly fine without procfs, or without given proc files and the
> removal works just fine if they don't exist either. This is a very
> common patter in various parts of the kernel already.
>
> I'll document it better in the changelog.
Thank you. That is the kind of thing that could be a signal of
inattentiveness and problems, especially when it is not documented.
Eric
Powered by blists - more mailing lists