On 22/05/15 14:44, Sergey Senozhatsky wrote:
On (05/22/15 11:12), Marcin Jabrzyk wrote:
no.
zram already complains about failed comp backend creation.
it's in dmesg (or syslog, etc.):
"zram: Cannot initialise %s compressing backend"
OK, now I see that. Sorry for the noise.
second, there is not much value in exposing zcomp internals,
especially when the result is just another line in dmesg output.
From the other hand, the only valid values that can be written are
in 'comp_algorithm'.
So when writing other one, returning -EINVAL seems to be reasonable.
The user would get immediately information that he can't do that,
now the information can be very deferred in time.
it's not.
the error message appears in syslog right before we return -EINVAL
back to user.
Yes I've read up the code more detailed and I saw that error message
just before returning to user with error value.
But this happens when 'disksize' is wirtten, not when 'comp_algorithm'.
I understood, the error message in dmesg is clear there is no such
algorithm.
But this is not an immediate error, when setting the 'comp_algorithm',
where we already know that it's wrong, not existing etc.
Anything after that moment would be wrong and would not work at all.
From what I saw 'comp_algorithm_store' is the only *_store in zram that
believes user that he writes proper value and just makes strlcpy.
So what I've ing mind is to provide direct feedback, you have
written wrong name of compressor, you got -EINVAL, please write
correct value. This would be very useful when scripting.
Sorry for being so confusing.
Best regards,
Marcin Jabrzyk
-ss
I'm not for exposing more internals, but getting -EINVAL would be nice I
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>