From nobody Thu Dec 1 14:59:05 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 4NNK3H0Ws5z4jQLZ for ; Thu, 1 Dec 2022 14:59:07 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNK3H020Qz44Mt; Thu, 1 Dec 2022 14:59:07 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669906747; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PQjblWP087F3X3sMkqL5Xzp/exCueikAunF9hdxTwRg=; b=SJIZ/hOEZG0Sl8v2wbKA9fx8BE6dXQbg9pqTiPZTQOIeE93yTkXuGK0OencY9cgklRg2vn ER2aXGl9rIpID67GLxRjyIS80MZ2Sfd/0CAUFpe0KefvGAXArZ0/tlrbvy+hwMjK7qdlil XqDgqz7Kwk4Pi5lXjYhqaNDVnD34plQT83TvwIOlhCNWyl3aAfA0sRYs/OUftWUoqjWQ7u xoYwD2QL8TxpuSAqHhrxShzr3t5vsLggjhyW5Bm4DvQjOrxb4s+4BXp8yVLF8H+W6pvCpY o1w8A1XQKicauyrG9M/gl2l6bMnXJJM3+cwD6kHCrpJ8jgPX9kFKs7660uk13w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669906747; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PQjblWP087F3X3sMkqL5Xzp/exCueikAunF9hdxTwRg=; b=VLm7hFMdXN6uQygBTlXIGpYC6YO8NHH5Q+EDMwM+j0b0nHW9/ziYx1VfmpZwTx4la4Whop AELgA674lO8LsEA8WzjCRVBRi6vlea4h7vSKn4F5M4Mh8Pu4jkp3+4IClumeRSKBxUcPTX gDDYZvpMBjDQaEq37ZEVKrzlxyVcl4tfoIc7VO1ZrXpNAS2z0Nwz0hRZ+oLBuZZj4bR+4M wPSsNhBOf4x41gVy/KE5YdnAkYlQy+5shh/GvZtgccStIx/ffeltvVKwnkmFZDPc8t+iH4 YoAJ+2Pz8gECxo7+4KnRAsC3c7Byv+gL/VL7HfNtZfBn9rXSMa3ymvcXZ/glOw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669906747; a=rsa-sha256; cv=none; b=Xg0bPI7txhvADjO2va6Zz1ZQ7PP0AgkFHJOCagWXSAo28JFCRumrchwlEQHwbkAtz7TNGW cvUTocU9itTCCDqEeGo1N3bxf8SpOf93KWQANjBHg/to0gO7Wjt2nkmEnNADYjZV7tIqFb mVNlMz/LsLwiMge/GXFh7RZGm/GqJnjwTFQApyugTgVGdYoo7cWHjhyIr+bFGZDRVREv0T zLMvVndnCqKWGIz1qoM3KV0GQ1S3wVsr0jmZK5TwnkTwuf8rFFjsHtL0ytIYiCpWarVcvF aLIK8mK5BdvNN0Jabpirglx7MKWBxZVOQ4ukiLofuaWuFL/3xoF40uRukQ8X7w== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NNK3G5T1Qz1QqC; Thu, 1 Dec 2022 14:59:06 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 57C61129F44; Thu, 1 Dec 2022 15:59:05 +0100 (CET) Date: Thu, 1 Dec 2022 15:59:05 +0100 From: Baptiste Daroussin To: Warner Losh Cc: hackers@freebsd.org Subject: Re: devctl_notify system is inconsistent Message-ID: <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N 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 via > > 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? > > > > 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 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 and > 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 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. > > > > 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 maintenance 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. Best regards, Bapt