All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: lvm-devel@redhat.com
Subject: LVM2/libdm/ioctl libdm-iface.c
Date: Mon, 21 Mar 2011 00:51:11 +0100	[thread overview]
Message-ID: <4D8692EF.1030400@redhat.com> (raw)
In-Reply-To: <20110320214149.GZ11163@agk-dp.fab.redhat.com>

Dne 20.3.2011 22:41, Alasdair G Kergon napsal(a):
> On Sun, Mar 20, 2011 at 02:09:13PM +0100, Zdenek Kabelac wrote:
>> My patch was only fixing error reporting logic.
>  
> One output case:
>   Failed to get device-mapper version
>   Support for older device-mapped version is disabled.
> 
> A quite misleading pair of messages, I think.

The order would be opposite - and I believe that giving the user knowledge,
that lvm lacks some part of code to handle this situation and code needs to be
recompiled with such support is IMHO good hint for error like this.

(Hmm typo -  device-mapper)

In fact -  Failed to get... should be probably log_warn

And also it's worth to know - we have 2 other log_error() already there:

--
dm_task_create: malloc(
--
Incompatible libdevmapper %s%s and kernel driver %s
--

Which might be printed together with "Failed to get..."

So that's why I've tried to add a bit more consistency (which strikes to my
eye with latest Milan's commit to this code).


> Another output case, when only one version is compiled into the binary:
>   ...
>   Support for older device-mapped version is disabled.
> 
> Support was not compiled in so we shouldn't mention anything about it to the
> user.

Well that's where I think 'root' should know why the operation failed.


>   We try to place it as low down in the code as we can consistent with
> minimising the number of log_errors: it is normally, but not always, at the
> lowest level.  
>   'stack' is used in other places on error paths.

The other way around would be to remove then all log_error below
dm_task_create() - and use there only log_debug/log_warn
(i.e. similar to dm_malloc() case where the actual error is defered)

Zdenek



  reply	other threads:[~2011-03-20 23:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-20  2:00 LVM2/libdm/ioctl libdm-iface.c agk
2011-03-20 13:09 ` Zdenek Kabelac
2011-03-20 21:41   ` Alasdair G Kergon
2011-03-20 23:51     ` Zdenek Kabelac [this message]
2011-03-21  1:47       ` Alasdair G Kergon
  -- strict thread matches above, loose matches on Subject: below --
2012-03-05 14:45 prajnoha
2012-03-01 10:46 zkabelac
2011-11-08 19:02 snitzer
2011-10-17 14:36 zkabelac
2011-09-23 17:16 agk
2011-09-22 18:00 prajnoha
2011-08-19 16:49 agk
2011-06-29 16:08 agk
2011-06-29 11:36 agk
2011-06-29  8:54 agk
2011-06-13  3:53 agk
2011-03-05 21:17 mbroz
2011-03-06  1:18 ` Alasdair G Kergon
2011-03-06  1:36   ` Milan Broz
2011-03-06  1:51     ` Alasdair G Kergon
2011-03-02  8:41 zkabelac
2011-02-04 21:26 agk
2011-01-31 11:54 prajnoha
2010-11-30 22:32 zkabelac
2010-08-16 11:13 prajnoha
2010-07-28 10:30 prajnoha
2010-05-03 22:08 prajnoha
2009-08-06 15:02 prajnoha

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 \
    --in-reply-to=4D8692EF.1030400@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=lvm-devel@redhat.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.