lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023081959-spinach-cherisher-b025@gregkh>
Date:   Sat, 19 Aug 2023 12:57:02 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Alistair Francis <alistair23@...il.com>
Cc:     bhelgaas@...gle.com, linux-pci@...r.kernel.org,
        Jonathan.Cameron@...wei.com, lukas@...ner.de,
        alex.williamson@...hat.com, christian.koenig@....com,
        kch@...dia.com, logang@...tatee.com, linux-kernel@...r.kernel.org,
        chaitanyak@...dia.com, rdunlap@...radead.org,
        Alistair Francis <alistair.francis@....com>
Subject: Re: [PATCH v6 2/3] sysfs: Add a attr_is_visible function to
 attribute_group

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."

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ