[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87blo4swy6.fsf@mpe.ellerman.id.au>
Date: Mon, 06 Apr 2020 20:57:53 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: afzal.mohd.ma@...il.com, agust@...x.de, aik@...abs.ru,
alistair@...ple.id.au,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
Arnd Bergmann <arnd@...db.de>, bala24@...ux.ibm.com,
Bjorn Helgaas <bhelgaas@...gle.com>, chenzhou10@...wei.com,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Christophe Leroy <christophe.leroy@....fr>, clg@...d.org,
courbet@...gle.com, Daniel Axtens <dja@...ens.net>,
dougmill@...ux.vnet.ibm.com, farosas@...ux.ibm.com,
ganeshgr@...ux.ibm.com, Grant Likely <grant.likely@....com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
gustavold@...ux.ibm.com, Ilie Halip <ilie.halip@...il.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
Joe Perches <joe@...ches.com>, kjain@...ux.ibm.com,
laurentiu.tudor@....com, leonardo@...ux.ibm.com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>, lpechacek@...e.cz,
maddy@...ux.ibm.com, maskray@...gle.com,
Nathan Chancellor <natechancellor@...il.com>,
nathanl@...ux.ibm.com,
"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nick Piggin <npiggin@...il.com>,
Olof Johansson <olof@...om.net>,
Oliver O'Halloran <oohall@...il.com>, oss@...error.net,
po-hsu.lin@...onical.com, psampat@...ux.ibm.com,
Mike Rapoport <rppt@...ux.ibm.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
shilpa.bhat@...ux.vnet.ibm.com, sourabhjain@...ux.ibm.com,
srikar@...ux.vnet.ibm.com, tyreld@...ux.ibm.com,
vaibhav@...ux.ibm.com, YueHaibing <yuehaibing@...wei.com>
Subject: Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.7-1 tag
Linus Torvalds <torvalds@...ux-foundation.org> writes:
> On Sun, Apr 5, 2020 at 5:53 AM Michael Ellerman <mpe@...erman.id.au> wrote:
>>
>> There is one conflict in fs/sysfs/group.c, between our:
>>
>> 9255782f7061 ("sysfs: Wrap __compat_only_sysfs_link_entry_to_kobj function to change the symlink name")
> [...]
>
> The conflict was trivial.
>
> But I want to kvetch a bit about that commit. It's doing some odd stuff.
>
> In particular, it's wrapping things "the wrong way". Our naming rules
> are that the double underscore versions are the internal helper
> functions that you generally shouldn't use unless you have some extra
> reason for it, and then the non-underscore versions are the preferred
> and simpler user interface to those internal implementations.
>
> IOW, the _wrapper_ doesn't have double underscores, it's the _wrappee_
> that has the underscores.
>
> That commit does the exact reverse of that usual pattern, which is
> very confusing.
>
> Now, I see _why_ you do that - normally the non-underscore version is
> the "real" interface and the one we've always exported, and then the
> double underscore is the special internal thing that maybe exposes
> some internal detail (or maybe only does one special case of it and
> leaves out locking or whatever).
>
> In this case, for hysterical raisins, we only _had_ that
> double-underscore version, and you basically added the new case and
> did it without the underscores.
>
> So I see why it happened the way it did, but I do think the end result
> makes no sense and is odd and surprising.
Yeah, that's fair.
I was a bit unsure about taking a fs/sysfs patch to begin with, so I
thought leaving the existing function unchanged was the least risky in
terms of causing any other breakage.
But in hindsight that was the wrong choice, the end result is not
actually what we want.
So we should have done the right patch and then either asked Greg to
take it or put it in a topic branch of my own.
> The thing is, we have exactly *one* user of that double-underscore
> version: tpm-chip.c (ok, there are two calls in that file, but it's a
> single user).
>
> So I think it should just have removed the __ version entirely. Make
> tpm-chip just use the new semantics, and pass in the extra NULL
> argument.
>
> I guess I'll just do that as a cleanup patch on top, but it feels a
> bit odd to have to do that cleanup when the original patch could have
> just done the obvious thing.
Thanks.
cheers
Powered by blists - more mailing lists