From: Guenter Roeck <firstname.lastname@example.org> To: Keith Busch <email@example.com>, Christoph Hellwig <firstname.lastname@example.org> Cc: Sagi Grimberg <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Akinobu Mita <email@example.com>, Jens Axboe <firstname.lastname@example.org>, Chris Healy <Chris.Healy@zii.aero> Subject: Re: [PATCH] nvme: Add hardware monitoring support Date: Mon, 28 Oct 2019 06:27:23 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20191028080858.GB1718@redsun51.ssa.fujisawa.hgst.com> On 10/28/19 1:08 AM, Keith Busch wrote: > On Mon, Oct 28, 2019 at 08:39:53AM +0100, Christoph Hellwig wrote: >> On Sun, Oct 27, 2019 at 07:41:56PM -0700, Guenter Roeck wrote: >>> nvme devices report temperature information in the controller information >>> (for limits) and in the smart log. Currently, the only means to retrieve >>> this information is the nvme command line interface, which requires >>> super-user privileges. >>> >>> At the same time, it would be desirable to use NVME temperature information >>> for thermal control. >>> >>> This patch adds support to read NVME temperatures from the kernel using the >>> hwmon API and adds temperature zones for NVME drives. The thermal subsystem >>> can use this information to set thermal policies, and userspace can access >>> it using libsensors and/or the "sensors" command. >> >> So these reported values seem to generate some interest. Adding Akinobu >> Mita who also planned to wire them up to the thermal framework. I don't >> really know either upper layer so I'm not sure which is the right one, >> but with this just like with the previous series I am quite worried that >> we add a lot of kernel boilerplate code for information people can >> trivially get using nvme-cli. > > I think it's nvme-cli requires root, where this conveniently doesn't > need those elevated rights. > The other point here is the thermal framework. One can not wire that up through userspace, and even if it was possible to do it, that would defeat the idea of having the thermal subsystem in the kernel running on its own, without requiring userspace attention. > I'm not familiar with either upper level framework either; my only review > comment for this patch is to use devm_kfree() for the error cases. > Makes sense. I'll address that in v2. Guenter _______________________________________________ Linux-nvme mailing list Linuxfirstname.lastname@example.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2019-10-28 13:27 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-28 2:41 Guenter Roeck 2019-10-28 7:39 ` Christoph Hellwig 2019-10-28 8:08 ` Keith Busch 2019-10-28 13:27 ` Guenter Roeck [this message] 2019-10-28 18:01 ` Andrey Smirnov
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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Chris.Healy@zii.aero \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] nvme: Add hardware monitoring support' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).