From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Linus Walleij <linus.walleij@linaro.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] gpio: updates for v5.13
Date: Mon, 3 May 2021 18:28:38 +0000 [thread overview]
Message-ID: <YJBA1iYK7npit9vn@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <CAHk-=whSWp3exv8tZ2th5im_P7HF=c6iuOOVb9iSrNrd6405WA@mail.gmail.com>
On Mon, May 03, 2021 at 11:03:57AM -0700, Linus Torvalds wrote:
> Al,
> would you mind taking a look at this part:
>
> On Sun, May 2, 2021 at 12:32 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > You'll notice that we have a bunch of configfs commits in our tree not acked by
> > the configfs maintainers. These commits implement the concept of committable
> > items in configfs - something that was well defined in the documentation for
> > years but has remained unimplemented. Despite the first submission of these
> > patches back in November 2020[1] and repeated pings & resending, configfs
> > maintainers have remained unresponsive. After reviewing these on the GPIO
> > mailing list, we decided to pick them up ourselves and send them your way
> > together with the first user: the new GPIO simulator.
>
> It doesn't look huge to me, and I don't care all that deeply about
> configfs, and honestly, I'm not seeing huge amounts of actual
> development there, with recent commits all being about cleanup of vfs
> changes (eg things like the new idmapping changes etc).
>
> That said, I really don't want to pull that with some core sanity checking.
>
> So Al, do you see anything horrendous in how that configfs thing uses
> a rename to do kind of an "atomic swap" of configfs state?
Give me a few hours; configfs is playing silly buggers with a lot of
structures when creating/tearing down subtrees, and I'd actually
expect more trouble with configfs data structures than with VFS ones.
I'll take a look.
next prev parent reply other threads:[~2021-05-03 18:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-02 19:32 [GIT PULL] gpio: updates for v5.13 Bartosz Golaszewski
2021-05-03 18:03 ` Linus Torvalds
2021-05-03 18:28 ` Al Viro [this message]
2021-05-03 18:29 ` Linus Torvalds
2021-05-04 1:55 ` Al Viro
2021-05-04 14:17 ` Bartosz Golaszewski
2021-05-04 17:34 ` Al Viro
2021-05-04 17:41 ` Andy Shevchenko
2021-05-05 14:19 ` Bartosz Golaszewski
2021-05-12 19:11 ` configfs: commitable items (was Re: [GIT PULL] gpio: updates for v5.13) Bartosz Golaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJBA1iYK7npit9vn@zeniv-ca.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.