Re: SYSFS "errors"

Em Mon, 18 Feb 2013 23:44:05 +0100
Borislav Petkov [off-list ref] escreveu:

On Mon, Feb 18, 2013 at 02:26:18PM -0800, Greg KH wrote:

quoted

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?

The thing with "sdram_scrub_rate" is that this is not supported by any
userspace application I know. I suspect that this is used by userspace
scripts. So, we'll never know in advance what behavior those scripts would
expect.

I'm not aware of any, frankly speaking.

If there are any, those tools should be able to handle the -ENODEV
they get. Now, if this gets changed this way, the read would succeed
but they'll have to parse the returned value and see that it is not an
integer.

So I don't know either.

But my gut feeling says to stay concervative and not touch this code -
we don't know what uses it and how much we would break by "fixing" it.
The current situation is not that big of a deal IMVHO and I'd be willing
to accept the small inconcistency versus possibly breaking userspace.

I remember I saw some discussions about it in the past at bluesmoke ML,
saying that -ENODEV is the expected behavior when this is not supported.

Changing from -ENODEV to "N/A" will break anything that would be relying
on the previous behavior. So, I think that such change will for sure break
userspace.

If we're willing to change it, not creating the "sdram_scrub_rate" sysfs 
node is less likely to affect userspace.

Regards,
Mauro