linux-kernel - Re: [PATCH 3/3] Documentation: ABI: sysfs-driver-regulator-output

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] [day] [month] [year] [list]

Message-ID: <d390b52b-c047-4db6-bf1f-ff2b47756f89@hatter.bewilderbeest.net>
Date:   Wed, 20 Sep 2023 03:53:25 -0700
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Naresh Solanki <naresh.solanki@...ements.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] Documentation: ABI: sysfs-driver-regulator-output

On Wed, Sep 20, 2023 at 03:48:00AM PDT, Greg Kroah-Hartman wrote:
>On Wed, Sep 20, 2023 at 03:44:29AM -0700, Zev Weiss wrote:
>> On Wed, Sep 20, 2023 at 02:29:15AM PDT, Greg Kroah-Hartman wrote:
>> > On Wed, Sep 20, 2023 at 02:02:49AM -0700, Zev Weiss wrote:
>> > >  static int regulator_userspace_notify(struct notifier_block *nb,
>> > >  				      unsigned long event,
>> > >  				      void *ignored)
>> > >  {
>> > >  	struct userspace_consumer_data *data =
>> > >  		container_of(nb, struct userspace_consumer_data, nb);
>> > > -	static const char * const *envp[] = { "NAME=events", NULL };
>> >
>> > You removed this user/kernel api value, what will break if you do that?
>> >
>>
>> Sorry, I don't follow -- what removal are you referring to?  The envp array
>> still has a NAME entry -- I changed its value from "events" to "event",
>
>Yes, that value.
>
>> but
>> I wrote that part before I realized that the 'event' parameter of the
>> function was actually a bitmask that might convey multiple events and just
>> forgot to change it back, so keeping it pluralized is probably more
>> appropriate.
>>
>> And FWIW, I didn't intend for the exact format of the EVENT parameter that I
>> sketched there to be something that had to be kept; given that there might
>> be multiple entries perhaps it'd be better to use separate parameters more
>> like NUMEVENTS, EVENT0, EVENT1, etc?  (Or omit NUMEVENTS and just let the
>> consumer count upward until it doesn't find a match.)
>
>I don't know, what does userspace do with this value today?  If you
>change it, what will break?
>

Unless there's something I'm not aware of, this is an entirely new 
interface being added, not a change to an existing one, so I don't think 
there's any existing userspace beyond draft/experimental code.  My patch 
was a relative one on top of Naresh's patch 2/3 in this series as a 
proposed amendment to it; the userspace-consumer driver as it presently 
exists in the mainline kernel doesn't have a uevent interface at all.


Zev