[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87eeota371.fsf@nanos.tec.linutronix.de>
Date: Thu, 30 Jul 2020 09:10:10 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Christoph Hellwig <hch@....de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Luis Chamberlain <mcgrof@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Kees Cook <keescook@...omium.org>,
Iurii Zaikin <yzaikin@...gle.com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 15/23] seq_file: switch over direct seq_read method calls to seq_read_iter
Al Viro <viro@...iv.linux.org.uk> writes:
> On Fri, Jul 17, 2020 at 11:09:13PM +0200, Thomas Gleixner wrote:
>>
>> Needs some thought and maybe some cocci help from Julia, but that's way
>> better than this brute force sed thing which results in malformed crap
>> like this:
>>
>> static const struct file_operations debug_stats_fops = {
>> .open = debug_stats_open,
>> .read_iter = seq_read_iter,
>> .llseek = seq_lseek,
>> .release = single_release,
>> };
>>
>> and proliferates the copy and paste voodoo programming.
>
> Better copy and paste than templates, IMO; at least the former is
> greppable; fucking DEFINE_..._ATRIBUTE is *NOT*, especially due
> to the use of ##.
Copy and paste itself is not the issue, but once the copy and paste orgy
starts you end up with more subtle bugs and silly differences than
copies. I spent enough time cleaning such crap up just to figure out
that once you've finished a full tree sweep you can start over.
grep for these things is a nuisance, but it's not rocket science to
figure it out. I rather have to figure that out than staring at a
gazillion of broken implementations.
Thanks,
tglx
Powered by blists - more mailing lists