From nobody Sat Dec 10 05:13:11 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NTbdJ63GVz4kcN2 for ; Sat, 10 Dec 2022 05:13:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NTbdJ3YnVz3LGm for ; Sat, 10 Dec 2022 05:13:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id gh17so16013113ejb.6 for ; Fri, 09 Dec 2022 21:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rYQE57+RDTI9/saLqypmDwmpunM/SGjT9YvuFtntVQ0=; b=0Z+DqEmLKFk44sv0YNm5fi240j1oJafN3Cv5ikJ2tBkDNEEi9V1sQz5XfWshPw3Aax 1TkotzysDctZGlQQyiW/lrABWkRrrQVp5z7ROLtI2sW5DmW7a9AoVpzi6e4G2jvd4VTp thRmMy/VRDSnohzq8uTTNd1bXBTa7LsTj5pmsvLOcXfc6KL2zjDK6iij+qnQBUpLBnAV VARj33KFqkpXhHW18nEml6sMhw5hinRVtikFoPSBBMBVL1G4aY2BYoNYbpObF0MPVFJD cIC0AccAerRym7bIDOLUxr1wb1Rn7ktyvrT7xJW8kXxrRkv7dllr2a2S6rLLIOdmBp7x FGnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rYQE57+RDTI9/saLqypmDwmpunM/SGjT9YvuFtntVQ0=; b=Gdgut5A3jvSH119eUplhvlqnObYUlSZW6atjB8VuGVj7M4ntB0ReMcb12HHKg6GeW1 Cjqwsh8ZqPr/ltAl9UCMus7OHK5cDCbG2uVQZ1iV4SV86yIX6IBaQDw+cqYr2PESjy24 PRZ9hlMuiubQRWYZj/5VLC/L2yYfAW7FgERMxroqUSpXlgFgBgTUaZVnkVsllCT2yo0j 88nurnJ3o4jo2nQ7I1s9ceQbLaaJqxWjTFjSbQ5IhjZsUk0q9DhiHealt/ZNB2wE1FY6 e/AjffoLaME1xqYFf1J+NoIUDdN8VhmxkiTJgike1hwwaa7crJ2Tzig+cnNM7ito/y86 KAOw== X-Gm-Message-State: ANoB5pkFBifWORnSZ89QU+ci2fGwkHExw/xesYTxBUPO7eYNpCTmUZiC ZlMRuhGABbkeBkKE01QCZ40b4pS/68r0l9KmalZh66xwH66E4A== X-Google-Smtp-Source: AA0mqf6Ocj1dQa8T7GVOiI960cvOxTRcSl5USUpyXr3Ee30bB2W+OAwLBTzsYn5OAdBjP1LeweOICJY2zZjMpU9ZJgs= X-Received: by 2002:a17:906:5a0c:b0:7c0:faca:4d5e with SMTP id mx12-20020a1709065a0c00b007c0faca4d5emr12432272ejc.140.1670649202442; Fri, 09 Dec 2022 21:13:22 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> <20221201174043.5yqtfbs6p63bdgqp@aniel.nours.eu> In-Reply-To: From: Warner Losh Date: Fri, 9 Dec 2022 22:13:11 -0700 Message-ID: Subject: Re: devctl_notify system is inconsistent To: "Alexander V. Chernikov" Cc: Baptiste Daroussin , hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000419eab05ef7254b6" X-Rspamd-Queue-Id: 4NTbdJ3YnVz3LGm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000419eab05ef7254b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 9, 2022 at 8:26 AM Alexander V. Chernikov wrote: > > > > On 1 Dec 2022, at 17:40, Baptiste Daroussin wrote: > > > > On Thu, Dec 01, 2022 at 08:38:37AM -0700, Warner Losh wrote: > >> On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin > wrote: > >> > >>> On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: > >>>> On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin > >>> wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> After the addition of netlink(4) by melifaro@, I started working on > a > >>> new > >>>>> genetlink(4) module, to send kernel notification to the userland vi= a > >>>>> netlink. > >>>>> > >>>>> The goal is to be able to have multiple consumers without the need = of > >>> devd > >>>>> to be > >>>>> running. > >>>>> > >>>>> The goal is also to be able subscribe to the events the consumer is > >>>>> willing to > >>>>> receive. > >>>>> > >>>>> https://reviews.freebsd.org/D37574 > >>>>> > >>>>> I also added a hook to devctl_notify to make sure all its event got > >>> sent > >>>>> via > >>>>> nlsysevent. (https://reviews.freebsd.org/D37573) > >>>>> > >>>> > >>>> You're connecting it at the wrong level: it will miss all device > events. > >>>> devctl_notify > >>>> is used by everything except newbus's device attach, detach and > nomatch > >>>> events, so none of those events will make it through. > >>> > >>> Where should I hook to get the device events? > >>> > >> > >> Either you need to drop down a level to where the formated events are > >> queued, > >> or you'll need to add something in devaddq() to deal with the events. > These > >> are > >> a slightly different format than the devctl_notify() events because th= e > >> latter was > >> added later and I didn't want to cope with transitioning the old > formatted > >> messages > >> to the new at that time (silly me). > >> > >> > >>>> > >>>> > >>>>> It works great and so far I am happy with it. on thing I figured ou= t > >>> it is: > >>>>> the "system" argment of devctl_notify is inconsistent: > >>>>> Upper case vs lower case > >>>>> "kern" vs "kernel" > >>>>> > >>>> > >>>> They are consistent. With one exception that I deprecated in 13.x to > be > >>>> removed in 14.x. I documented all of them at the time in devd.conf. = I > >>> think > >>>> I'll go ahead and complete the deprecation. > >>>> > >>>> > >>>>> I intent to fix the following way: > >>>>> Create a new function similar to devctl_notify but with the first > >>> argument > >>>>> being > >>>>> an enum. > >>>>> > >>>> > >>>> I'm a pretty hard no on the enum. I rejected doing it that way when = I > >>> wrote > >>>> devd > >>>> years ago. These have always been strings, and need to continue to > >>> always be > >>>> strings, or we're forever modifying devd(8) when we add a new one an= d > >>>> introducing > >>>> yet another opportunity for mismatch. I don't think this is a good > idea > >>> at > >>>> all. > >>>> > >>>> There's been users of devd in the past that are loadable modules tha= t > >>> pass > >>>> their > >>>> own system name in that devd.conf files would then process. Having a= n > >>> enum > >>>> with > >>>> enforcement would just get in the way of this. > >>>> > >>>> I have toyed with the idea of having a centralized list in bus.h > that's a > >>>> bunch of > >>>> #defines, ala old-school X11 resources (which this is very very > loosely > >>>> based on), > >>>> but it didn't seem worth the effort. > >>> > >>> That is fine with me and actually I do need the string name to > register as > >>> group > >>> name, that I didn't want to trash the strings away. > >>> > >>> But I need a way to list them all. > >>> > >> > >> We have no current mechanism to do that. We could add something that > would > >> register / deregister them with a sysinit + call to something in > >> kern_devctl.c which > >> could do the trick (and also deal with the ordering issues), though > having > >> netlink(4) > >> as a loadable modules might be an interesting case to get right. > >> > >> If we did that, we could return a 'token' that you'd use to call a new > >> version of > >> devctl_notify(), perhaps with some glue for legacy users (or perhaps > not: > >> we change > >> kernel interfaces all the time, and could just rename it and convert > >> everything in the > >> tree). > >> > >>> > >>>> > >>>>> Make the current devctl_notify convert its first argument into that > >>> enum > >>>>> and > >>>>> yell if an unkwown "system" is passed. (and probably declare > >>> devctl_notify > >>>>> deprecated) > >>>>> > >>>> > >>>> I don't think this buys us anything. devctl_notify cannot possibly > know > >>>> about all > >>>> the possible subsystems, so this is likely doomed to high maintenanc= e > >>> that > >>>> would > >>>> be largely ineffective. > >>>> > >>>> Then fix the inconsistencies: all upper case as it seems the most > wildly > >>> use > >>>>> case > >>>>> s/kern/kernel/g > >>>>> > >>>>> WDYT? > >>>>> > >>>> > >>>> I wouldn't worry about the upper vs lower case. All the documented > ones > >>> are > >>>> upper case, except kernel. There's no harm it being one exception > since > >>>> changing > >>>> it will break user's devd.conf setups. I got enough feedback when I > >>> changed > >>>> "kern" to "kernel" last year for power events. And as far as I know, > I've > >>>> documented > >>>> all the events that are generated today. > >>>> > >>>> Warner > >>> > >>> > >>> Note that if you think nlsysevent is a bad idea, I will just forget > about > >>> it. > >>> > >> > >> I love the idea. I got over any resistance I had when melifaro@ moved > >> things into kern_devctl.c and we talked through the issues at that tim= e. > >> I've been hoping that someone would replace the hacky thing I did with > >> a 'routing socket'-like interface (I never could figure out hose to do > it so > >> many years ago w/o gross hacks). netlink(4) has finally provided a way > >> to do it that doesn't get the routing code all jumbled up for this. > >> > >> I just have some specific issues with your proposal. In hindsight, I > should > >> have led with that in my first message :). > >> > >> Warner > > > > Here is my new proposal: > > > > What about: > > > > 1. I add a static list of systems in sys/devctl.h something like > > > > enum { > > DEVCTL_SYSTEM_ACPI =3D 0, > > DEVCTL_SYSTEM_AEON =3D 1, > > ... > > DEVCTL_SYSTEM_ZFS =3D 19 > > }; > > > > static const char *devctl_systems[] =3D { > > "ACPI", > > "AEON", > > ... > > "ZFS", > > }; > > > > this way we have a list of official freebsd's systems. > > We don't change the devctl_notify interface > > > > and in the kernel we change the devctl_notify("ZFS" into > > devctl_notify(devctl_systems[DEVCTL_SYSTEM_ZFS],... > > > > This is not too intrusive, and breaks none of the existing code > > > > 2. I also hook devadq using the same interface as I already have done, > but > > all the attach,detach,nomatch become an event (only in nlsysevent) in t= he > > "DEVICE" system, > > the "SUBSYSTEM" is the current what of devaddq > > > > The type is changed into: > > + -> ATTACH > > - -> DETACH > > anythingelse -> NOMATCH > > and the reste of the current line becomes the data > > > > so from nlsysvent point of view this is exactly the same kind of events > as the > > one hooked in devctl_notify. > > > > 3. in nlsysevent we have one category one can subscribe per known > systems. > > All other "systems" falls into a new category named "extra" "vendor" or > "other" > > > > from the consumer point of view the name of the system is anyway > contained in > > the message itself, so the category it is subscribed to can differ. > > > > This way, I should be able to get ALL the events in a consistent way. > > I should be compatible with people who uses devctl_notify in their > custom kernel > > modules. > > > > Sounds easy enough without the requirement of complexifying > kern_devctl.c with a > > registration of extra systems. > > > > What do you think? > My 2 cents: > > I=E2=80=99d look at the groups from the customer (e.g. userland API POV).= IMHO, > fine-grained groups serves 2 purposes. > The first is limiting the amount of notifications the app has to deal wit= h. Yea, that breaks devd. It assumes it can 'catch up' on events that happened before it got around to running and registering. > The second is moving filtering from the > application to the kernel, so the app doesn=E2=80=99t need to check the e= vent=E2=80=99s > subsystem. Note that the second part loses its value if the app subscribe= s > for more than one group. > It is also worth noting that _some_ notifications, like ifnet event, may > be high-volume, so it can be desirable to have a way to filter them out. > For example, it can be implemented as a fixed number of broad group > categories (=E2=80=9Cnet=E2=80=9D, =E2=80=9Cdevice=E2=80=9D, =E2=80=9Cfs= =E2=80=9D, =E2=80=9Cpower=E2=80=9D, =E2=80=9Cvendor=E2=80=9D) and each subs= ystem > picks one it belongs to. > It can be potentially extended with an ability to register custom groups > if so desired. > I wouldn=E2=80=99t say the existing KPI consisting of a single devctl_not= ify() is > set in stone. I=E2=80=99d actually vote to have a new function/set of fun= ctions, as > the notifications are no longer limited to the devices, as devctl suggest= s. > I'm not sure I see the value in kernel filtering. The data rates are low. The number of apps is also low, so the savings is tiny today. > For example (just to illustrate the point): > group_id =3D unotify_get_group(=E2=80=9Cpower=E2=80=9D) # gets existing o= r registers new > group in the netlink subsystem > unotify_broadcast(group_id, =E2=80=9CACPI=E2=80=9D, =E2=80=A6) > unotify_free_group(group_id) > I see no value in this with the current base of consumers / producers. It sounds cool, but at the present time the data rates are so low that the extra complexity of filtering in the kernel likely would dwarf doing it in userland. Warner > > > > Best regards, > > Bapt > > > > --000000000000419eab05ef7254b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 9, 2022 at 8:26 AM Alexan= der V. Chernikov <melifaro@ipfw.ru> wrote:

> On 1 Dec 2022, at 17:40, Baptiste Daroussin <bapt@FreeBSD.org> w= rote:
>
> On Thu, Dec 01, 2022 at 08:38:37AM -0700, Warner Losh wrote:
>> On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin <bapt@freebsd.org> wrote: >>
>>> On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: >>>> On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin <bapt@freebsd.org><= br> >>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> After the addition of netlink(4) by melifaro@, I start= ed working on a
>>> new
>>>>> genetlink(4) module, to send kernel notification to th= e userland via
>>>>> netlink.
>>>>>
>>>>> The goal is to be able to have multiple consumers with= out the need of
>>> devd
>>>>> to be
>>>>> running.
>>>>>
>>>>> The goal is also to be able subscribe to the events th= e consumer is
>>>>> willing to
>>>>> receive.
>>>>>
>>>>> https://reviews.freebsd.org/D37574
>>>>>
>>>>> I also added a hook to devctl_notify to make sure all = its event got
>>> sent
>>>>> via
>>>>> nlsysevent. (https://reviews.freebsd.org/D375= 73)
>>>>>
>>>>
>>>> You're connecting it at the wrong level: it will miss = all device events.
>>>> devctl_notify
>>>> is used by everything except newbus's device attach, d= etach and nomatch
>>>> events, so none of those events will make it through.
>>>
>>> Where should I hook to get the device events?
>>>
>>
>> Either you need to drop down a level to where the formated events = are
>> queued,
>> or you'll need to add something in devaddq() to deal with the = events. These
>> are
>> a slightly different format than the devctl_notify() events becaus= e the
>> latter was
>> added later and I didn't want to cope with transitioning the o= ld formatted
>> messages
>> to the new at that time (silly me).
>>
>>
>>>>
>>>>
>>>>> It works great and so far I am happy with it. on thing= I figured out
>>> it is:
>>>>> the "system" argment of devctl_notify is inc= onsistent:
>>>>> Upper case vs lower case
>>>>> "kern" vs "kernel"
>>>>>
>>>>
>>>> They are consistent. With one exception that I deprecated = in 13.x to be
>>>> removed in 14.x. I documented all of them at the time in d= evd.conf. I
>>> think
>>>> I'll go ahead and complete the deprecation.
>>>>
>>>>
>>>>> I intent to fix the following way:
>>>>> Create a new function similar to devctl_notify but wit= h the first
>>> argument
>>>>> being
>>>>> an enum.
>>>>>
>>>>
>>>> I'm a pretty hard no on the enum. I rejected doing it = that way when I
>>> wrote
>>>> devd
>>>> years ago. These have always been strings, and need to con= tinue to
>>> always be
>>>> strings, or we're forever modifying devd(8) when we ad= d a new one and
>>>> introducing
>>>> yet another opportunity for mismatch. I don't think th= is is a good idea
>>> at
>>>> all.
>>>>
>>>> There's been users of devd in the past that are loadab= le modules that
>>> pass
>>>> their
>>>> own system name in that devd.conf files would then process= . Having an
>>> enum
>>>> with
>>>> enforcement would just get in the way of this.
>>>>
>>>> I have toyed with the idea of having a centralized list in= bus.h that's a
>>>> bunch of
>>>> #defines, ala old-school X11 resources (which this is very= very loosely
>>>> based on),
>>>> but it didn't seem worth the effort.
>>>
>>> That is fine with me and actually I do need the string name to= register as
>>> group
>>> name, that I didn't want to trash the strings away.
>>>
>>> But I need a way to list them all.
>>>
>>
>> We have no current mechanism to do that. We could add something th= at would
>> register / deregister them with a sysinit + call to something in >> kern_devctl.c which
>> could do the trick (and also deal with the ordering issues), thoug= h having
>> netlink(4)
>> as a loadable modules might be an interesting case to get right. >>
>> If we did that, we could return a 'token' that you'd u= se to call a new
>> version of
>> devctl_notify(), perhaps with some glue for legacy users (or perha= ps not:
>> we change
>> kernel interfaces all the time, and could just rename it and conve= rt
>> everything in the
>> tree).
>>
>>>
>>>>
>>>>> Make the current devctl_notify convert its first argum= ent into that
>>> enum
>>>>> and
>>>>> yell if an unkwown "system" is passed. (and = probably declare
>>> devctl_notify
>>>>> deprecated)
>>>>>
>>>>
>>>> I don't think this buys us anything. devctl_notify can= not possibly know
>>>> about all
>>>> the possible subsystems, so this is likely doomed to high = maintenance
>>> that
>>>> would
>>>> be largely ineffective.
>>>>
>>>> Then fix the inconsistencies: all upper case as it seems t= he most wildly
>>> use
>>>>> case
>>>>> s/kern/kernel/g
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> I wouldn't worry about the upper vs lower case. All th= e documented ones
>>> are
>>>> upper case, except kernel. There's no harm it being on= e exception since
>>>> changing
>>>> it will break user's devd.conf setups. I got enough fe= edback when I
>>> changed
>>>> "kern" to "kernel" last year for power= events. And as far as I know, I've
>>>> documented
>>>> all the events that are generated today.
>>>>
>>>> Warner
>>>
>>>
>>> Note that if you think nlsysevent is a bad idea, I will just f= orget about
>>> it.
>>>
>>
>> I love the idea. I got over any resistance I had when melifaro@ mo= ved
>> things into kern_devctl.c and we talked through the issues at that= time.
>> I've been hoping that someone would replace the hacky thing I = did with
>> a 'routing socket'-like interface (I never could figure ou= t hose to do it so
>> many years ago w/o gross hacks). netlink(4) has finally provided a= way
>> to do it that doesn't get the routing code all jumbled up for = this.
>>
>> I just have some specific issues with your proposal. In hindsight,= I should
>> have led with that in my first message :).
>>
>> Warner
>
> Here is my new proposal:
>
> What about:
>
> 1. I add a static list of systems in sys/devctl.h something like
>
> enum {
> DEVCTL_SYSTEM_ACPI =3D 0,
> DEVCTL_SYSTEM_AEON =3D 1,
> ...
> DEVCTL_SYSTEM_ZFS =3D 19
> };
>
> static const char *devctl_systems[] =3D {
>=C2=A0 "ACPI",
>=C2=A0 "AEON",
>=C2=A0 ...
>=C2=A0 "ZFS",
> };
>
> this way we have a list of official freebsd's systems.
> We don't change the devctl_notify interface
>
> and in the kernel we change the devctl_notify("ZFS" into
> devctl_notify(devctl_systems[DEVCTL_SYSTEM_ZFS],...
>
> This is not too intrusive, and breaks none of the existing code
>
> 2. I also hook devadq using the same interface as I already have done,= but
> all the attach,detach,nomatch become an event (only in nlsysevent) in = the
> "DEVICE" system,
> the "SUBSYSTEM" is the current what of devaddq
>
> The type is changed into:
> + -> ATTACH
> - -> DETACH
> anythingelse -> NOMATCH
> and the reste of the current line becomes the data
>
> so from nlsysvent point of view this is exactly the same kind of event= s as the
> one hooked in devctl_notify.
>
> 3. in nlsysevent we have one category one can subscribe per known syst= ems.
> All other "systems" falls into a new category named "ex= tra" "vendor" or "other"
>
> from the consumer point of view the name of the system is anyway conta= ined in
> the message itself, so the category it is subscribed to can differ. >
> This way, I should be able to get ALL the events in a consistent way.<= br> > I should be compatible with people who uses devctl_notify in their cus= tom kernel
> modules.
>
> Sounds easy enough without the requirement of complexifying kern_devct= l.c with a
> registration of extra systems.
>
> What do you think?
My 2 cents:

I=E2=80=99d look at the groups from the customer (e.g. userland API POV). I= MHO, fine-grained groups serves 2 purposes.
The first is limiting the amount of notifications the app has to deal with.=

Yea, that breaks devd. It assumes it can &= #39;catch up' on events that happened before it got around to running a= nd registering.
=C2=A0
The second is moving filtering from the
application to the kernel, so the app doesn=E2=80=99t need to check the eve= nt=E2=80=99s subsystem. Note that the second part loses its value if the ap= p subscribes for more than one group.
It is also worth noting that _some_ notifications, like ifnet event, may be= high-volume, so it can be desirable to have a way to filter them out.
For example, it can be implemented as a fixed number of broad group categor= ies (=E2=80=9Cnet=E2=80=9D, =E2=80=9Cdevice=E2=80=9D, =E2=80=9Cfs=E2=80=9D,= =E2=80=9Cpower=E2=80=9D, =E2=80=9Cvendor=E2=80=9D) and each subsystem pick= s one it belongs to.
It can be potentially extended with an ability to register custom groups if= so desired.
I wouldn=E2=80=99t say the existing KPI consisting of a single devctl_notif= y() is set in stone. I=E2=80=99d actually vote to have a new function/set o= f functions, as the notifications are no longer limited to the devices, as = devctl suggests.

I'm not sure I see= the value in kernel filtering. The data rates are low. The number of apps = is also low, so the savings is tiny today.
=C2=A0
For example (just to illustrate the= point):
group_id =3D unotify_get_group(=E2=80=9Cpower=E2=80=9D) # gets existing or = registers new group in the netlink subsystem
unotify_broadcast(group_id, =E2=80=9CACPI=E2=80=9D, =E2=80=A6)
unotify_free_group(group_id)

I see no v= alue in this with the current base of consumers / producers. It sounds cool= , but at the present time the data rates are so low that the extra complexi= ty of filtering in the kernel likely would dwarf doing it in userland.

Warner
=C2=A0
>
> Best regards,
> Bapt
>

--000000000000419eab05ef7254b6--