BmapCopy: downgrade inability to set sysfs parameters to a warning
authorSimon McVittie <smcv@debian.org>
Tue, 25 Jun 2013 11:56:28 +0000 (12:56 +0100)
committerArtem Bityutskiy <artem.bityutskiy@intel.com>
Wed, 3 Jul 2013 13:28:01 +0000 (16:28 +0300)
commitd96e613d35f173a8bc1058b8f033ce58db4f9034
tree4fb7e75e54817512ac0d22760968a5106b91a317
parentb07fdd91ae86863b61405984952406fbc9951fa4
BmapCopy: downgrade inability to set sysfs parameters to a warning

On distributions where unprivileged users can write to removable
USB disks, this allows such a disk to be written with bmaptool
(albeit with non-optimal performance) without being root.

Artem: got some more explanations from Simon McVittie
<simon.mcvittie@collabora.co.uk> about why we don't just add a special
case for EPERM/EACCESS:

"""
> On 28/06/13 12:47, Artem Bityutskiy wrote:
> For a library, requiring the user to have a logger object is probably
> not the nicest thing. And usually libraries do not print error messages,
> they throw exceptions instead.

I made the logger optional: if the caller doesn't supply one, BmapCopy
will use logging.getLogger(__name__), i.e. the logger named
"bmaptools.BmapCopy", which appears to be best-practice for Python
logging. (You could use it for debug-logging too, if you wanted to.)

Having logger=None cause logging to be suppressed, instead of using the
logging module's defaults (which are to print 'No handlers could be
found for logger "foo.bar"' the first time you use it, and not log
anything...) would also be fine.

Libraries throw exceptions if they couldn't do what you asked, but I
think there's some room for a middle ground between "no, I can't" and
silent success.
"""

Fair enough, I think.

Hoewver, I massged the patch a bit and improved the warnings to make
them a bit more user-friendly and give users the idea what is the
consequence of the warning.

Change-Id: I644d9777b7bf9e97dbe002814f7d4e411a7618db
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@intel.com>
bmaptools/BmapCopy.py