Re: SYSFS "errors"
From: Greg KH <gregkh@linuxfoundation.org>
Date: 2013-02-18 22:26:28
Also in:
linux-pm, linux-scsi, lkml
Possibly related (same subject, not in this thread)
- 2013-02-19 · Re: SYSFS "errors" · Felipe Balbi <hidden>
On Mon, Feb 18, 2013 at 11:13:06PM +0100, Borislav Petkov wrote:
quoted hunk ↗ jump to hunk
On Mon, Feb 18, 2013 at 01:54:34PM -0800, Greg KH wrote:quoted
Because sysfs is "one value per file" the lack of a file showing up shouldn't cause any userspace tools any problems, that is why we did things this way. But, of course, userspace programmers do know how to mess things up...How about what I proposed earlier to Felipe: --diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c index 0ca1ca71157f..d2eef76d1d46 100644 --- a/drivers/edac/edac_mc_sysfs.c +++ b/drivers/edac/edac_mc_sysfs.c@@ -704,7 +704,7 @@ static ssize_t mci_sdram_scrub_rate_show(struct device *dev, int bandwidth = 0; if (!mci->get_sdram_scrub_rate) - return -ENODEV; + return sprintf(data, "N/A"); bandwidth = mci->get_sdram_scrub_rate(mci); if (bandwidth < 0) { --Would that hurt the sysfs policy? In this case we *can* read the file and it correctly tells us that scrub rate reading is not supported instead of having a number there. Hmm.
I don't know, it depends on if userspace can handle this properly or not. What tools rely on this sysfs file? WHat happens when they get a non-number in the file? thanks, greg k-h