From: Guenter Roeck <linux@roeck-us.net>
To: Jihong Min <hurryman2212@gmail.com>
Cc: linux-hwmon@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
linux-api@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] docs: hwmon: Document the uhwmon userspace interface
Date: Mon, 19 Oct 2026 15:38:46 -0700 [thread overview]
Message-ID: <4cb23fc0-2939-4ac7-ba0d-c7e0906434d8@roeck-us.net> (raw)
In-Reply-To: <CAAwencqEVCjtnJfmnut2zXXPvuwju5T89FDSpHN3wPfrrJnRdQ@mail.gmail.com>
On 10/18/26 10:27, Jihong Min wrote:
> Ok. Then I will withdraw these patch series.
>
> But then let me ask you the initial question that brought this patch series: Do you think it is at least OK to add kernel drivers for network-based sensors? Or do you think those are also to be subjected to be rejected (or remained in DKMS projects)?
>
What is a "network-based sensor" ?
Regarding the references, wireview has a USB interface, and I am
quite sure that it should be possible to write a kernel driver for it.
There are several hwmon kernel drivers implementing access through USB,
so the same should be possible here.
The Tapo API reference points to an "Unofficial Tapo API client",
written in AI-guided Rust. Google tells me:
"
There is no official public API documentation released by TP-Link for
Tapo smart devices. Because Tapo uses a cloud-centric and encrypted
local communication protocol, developers rely entirely on
reverse-engineered, community-driven API clients to interact with
these devices locally or via the cloud.
"
I have no idea if it is possible to implement a kernel driver for
this. There are various hwmon drivers with reverse engineered APIs
(such as the Corsair power supply drivers), so relying on reverse
engineering is not a problem. I am, however, not going to dig through
the above mentioned clients to figure out what the API actually is
and how to use it. The guidance provided by Google suggests that
it requires per-client credentials (account email and password),
which would be problematic.
Either case, it appears that this would be about monitoring remote
devices. That is really out of scope for the hardware monitoring
subsystem. The hardware monitoring subsystem is monitoring _this_
system. Adding support for monitoring remote devices would be
a stretch.
Guenter
>
> Sincerely,
> Jihong Min
>
> On Mon, Oct 19, 2026 at 01:06 Guenter Roeck <linux@roeck-us.net <mailto:linux@roeck-us.net>> wrote:
>
> On Sat, Oct 10, 2026 at 12:38:44AM +0900, Jihong Min wrote:
> > Document the uhwmon UAPI for developers implementing userspace hwmon
> > drivers. Cover device registration, request handling, notifications
> > and device lifetime.
> >
> > Assisted-by: Codex:gpt-6-astra
> > Signed-off-by: Jihong Min <hurryman2212@gmail.com <mailto:hurryman2212@gmail.com>>
>
> I am not going to review, much less apply, this series.
> Exposing subsystem internals to userspace is a bad idea and would limit
> future improvements of the hardware monitoring subsystem. User space file
> systems are bad enough and cause all kinds of trouble. I don't want to have
> to deal with the same kind of issues in the hardware monitoring subsystem.
>
> Interested parties should implement kernel hardware monitoring
> drivers instead.
>
> Guenter
>
prev parent reply other threads:[~2026-10-19 22:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 15:38 [PATCH 0/5] hwmon: Introduce uhwmon for userspace implementations Jihong Min
2026-10-09 15:38 ` [PATCH 1/5] hwmon: Export sensor and attribute definitions to userspace Jihong Min
2026-10-18 15:52 ` Guenter Roeck
2026-10-09 15:38 ` [PATCH 2/5] hwmon: Expose attribute validation and string helpers Jihong Min
2026-10-09 15:38 ` [PATCH 3/5] hwmon: Add a generic interface for userspace implementations Jihong Min
2026-10-10 14:50 ` Markus Elfring
2026-10-09 15:38 ` [PATCH 4/5] hwmon: Reject truncated attribute names Jihong Min
2026-10-09 15:38 ` [PATCH 5/5] docs: hwmon: Document the uhwmon userspace interface Jihong Min
2026-10-18 16:06 ` Guenter Roeck
2026-10-18 17:30 ` Jihong Min
[not found] ` <CAAwencqEVCjtnJfmnut2zXXPvuwju5T89FDSpHN3wPfrrJnRdQ@mail.gmail.com>
2026-10-19 22:38 ` Guenter Roeck [this message]
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=4cb23fc0-2939-4ac7-ba0d-c7e0906434d8@roeck-us.net \
--to=linux@roeck-us.net \
--cc=corbet@lwn.net \
--cc=hurryman2212@gmail.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.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
all inboxes | Powered by JetHome®