From: Alistair Francis <alistair23@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
Jonathan.Cameron@huawei.com, lukas@wunner.de,
alex.williamson@redhat.com, christian.koenig@amd.com,
kch@nvidia.com, logang@deltatee.com,
linux-kernel@vger.kernel.org, chaitanyak@nvidia.com,
rdunlap@infradead.org,
Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [PATCH v6 2/3] sysfs: Add a attr_is_visible function to attribute_group
Date: Tue, 22 Aug 2023 16:20:06 -0400 [thread overview]
Message-ID: <CAKmqyKM+DNTF1f0FvDEda_db792Ta4w_uAKNTZ6E3NkYoVcPFQ@mail.gmail.com> (raw)
In-Reply-To: <2023081959-spinach-cherisher-b025@gregkh>
On Sat, Aug 19, 2023 at 6:57 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Aug 17, 2023 at 07:58:09PM -0400, Alistair Francis wrote:
> > The documentation for sysfs_merge_group() specifically says
> >
> > This function returns an error if the group doesn't exist or any of the
> > files already exist in that group, in which case none of the new files
> > are created.
> >
> > So just not adding the group if it's empty doesn't work, at least not
> > with the code we currently have. The code can be changed to support
> > this, but it is difficult to determine how this will affect existing use
> > cases.
>
> Did you try? I'd really really really prefer we do it this way as it's
> much simpler overall to have the sysfs core "do the right thing
> automatically" than to force each and every bus/subsystem to have to
> manually add this type of attribute.
>
> Also, on a personal level, I want this function to work as it will allow
> us to remove some code in some busses that don't really need to be there
> (dynamic creation of some device attributes), which will then also allow
> me to remove some apis in the driver core that should not be used at all
> anymore (but keep creeping back in as there is still a few users.)
>
> So I'll be selfish here and say "please try to get my proposed change to
> work, it's really the correct thing to do here."
I did try!
This is an attempt:
https://github.com/alistair23/linux/commit/56b55756a2d7a66f7b6eb8a5692b1b5e2f81a9a9
It is based on your original patch with a bunch of:
if (!parent) {
parent = kernfs_create_dir_ns(kobj->sd, grp->name,
S_IRWXU | S_IRUGO | S_IXUGO,
uid, gid, kobj, NULL);
...
}
added throughout the code base.
Very basic testing shows that it does what I need it to do and I don't
see any kernel oops on boot.
I prefer the approach I have in this mailing list patch. But if you
like the commit mentioned above I can tidy and clean it up and then
use that instead
Alistair
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2023-08-22 20:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 23:58 [PATCH v6 1/3] PCI/DOE: Expose the DOE features via sysfs Alistair Francis
2023-08-17 23:58 ` [PATCH v6 2/3] sysfs: Add a attr_is_visible function to attribute_group Alistair Francis
2023-08-18 0:35 ` Damien Le Moal
2023-08-19 10:57 ` Greg KH
2023-08-22 20:20 ` Alistair Francis [this message]
2023-08-23 7:02 ` Greg KH
2023-08-28 5:05 ` Alistair Francis
2023-08-31 8:31 ` Greg KH
2023-08-31 14:36 ` Greg KH
2023-09-01 21:00 ` Greg KH
2023-10-05 13:05 ` Greg KH
2023-10-11 5:10 ` Alistair Francis
2023-10-11 6:44 ` Greg KH
2023-10-12 4:31 ` Alistair Francis
2024-01-23 4:04 ` Alistair Francis
2024-01-23 12:25 ` Greg KH
2024-01-24 20:31 ` Dan Williams
2024-01-26 18:58 ` Dan Williams
2024-01-26 19:07 ` Greg KH
2024-01-26 20:08 ` Dan Williams
2024-01-27 3:00 ` Dan Williams
2024-01-28 0:21 ` Greg KH
2024-01-28 1:42 ` Dan Williams
2024-01-28 14:53 ` Greg KH
2023-08-17 23:58 ` [PATCH v6 3/3] PCI/DOE: Only expose the sysfs attribute group if DOE is supported Alistair Francis
2023-08-18 4:52 ` [PATCH v6 1/3] PCI/DOE: Expose the DOE features via sysfs Chaitanya Kulkarni
2023-08-18 5:48 ` kernel test robot
2023-08-21 21:07 ` kernel test robot
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=CAKmqyKM+DNTF1f0FvDEda_db792Ta4w_uAKNTZ6E3NkYoVcPFQ@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=bhelgaas@google.com \
--cc=chaitanyak@nvidia.com \
--cc=christian.koenig@amd.com \
--cc=gregkh@linuxfoundation.org \
--cc=kch@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=lukas@wunner.de \
--cc=rdunlap@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).