From: Marius Vollmer <marius.vollmer@redhat.com>
To: Peter Rajnoha <prajnoha@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Identifying useable block devices
Date: Fri, 24 Jan 2014 16:39:02 +0200 [thread overview]
Message-ID: <87wqhp4f7d.fsf@red.mvo.lan> (raw)
In-Reply-To: <52E26AD3.7080203@redhat.com>
Peter Rajnoha <prajnoha@redhat.com> writes:
>> The flag (DM_UDEV_DISABLE_OTHER_RULES_FLAG) is here to direct
>> udev processing to skip any scans - it's not actually saying
>> everyone else should remove this device now. It's just saying
>> "don't access/touch it" when this flag is set. If there was a
>> situation where we really need to remove (deactivate) the device,
>> we'd do that in lvm2 directly within processing of the device.
>
> ...simply, the event listener that gets the event with this flag
> set should just consider this dm device as "private".
Yeah, that's what treating events with the flag as a "remove" event is
meant to accomplish.
UDisks2 maintains objects on D-Bus corresponding to public udev block
devices. When a device changes from public to private, we should remove
the corresponding object from D-Bus. The code for that is the same as
when UDisks2 receives a "remove" event for the device AFAICS, so we just
jump into that code path by changing the event action early on.
The alternative is to also create D-Bus objects for private udev block
devices, but set UDISKS_IGNORE for them (and rely on its clients to dtrt
with that). I think that is what UDisks 1 used to do, but David has
choosen not to do this for UDisks2. I can't really judge which approach
is better. Do you have an opinion?
next prev parent reply other threads:[~2014-01-24 14:39 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 8:19 [linux-lvm] Identifying useable block devices Marius Vollmer
2014-01-15 15:49 ` Alasdair G Kergon
2014-01-15 16:17 ` Oliver Rath
2014-01-15 20:24 ` Anatoly Pugachev
2014-01-16 1:32 ` Paul B. Henson
2014-01-16 5:42 ` Peter Rajnoha
2014-01-16 21:03 ` Paul B. Henson
2014-01-17 7:54 ` Peter Rajnoha
2014-01-17 9:29 ` Karel Zak
2014-01-17 9:53 ` Peter Rajnoha
2014-01-16 6:04 ` Peter Rajnoha
2014-01-17 10:02 ` Marius Vollmer
2014-01-17 13:35 ` Marius Vollmer
2014-01-20 11:52 ` Peter Rajnoha
2014-01-20 11:49 ` Peter Rajnoha
2014-01-20 12:02 ` Peter Rajnoha
2014-01-22 9:23 ` Marius Vollmer
2014-01-23 11:42 ` Peter Rajnoha
2014-01-23 12:35 ` Marius Vollmer
2014-01-24 13:24 ` Peter Rajnoha
2014-01-24 13:29 ` Peter Rajnoha
2014-01-24 14:39 ` Marius Vollmer [this message]
2014-01-24 15:02 ` Peter Rajnoha
2014-01-27 7:37 ` Marius Vollmer
2014-01-24 14:50 ` Marius Vollmer
2014-01-24 15:08 ` Peter Rajnoha
2014-01-24 15:17 ` Zdenek Kabelac
2014-01-24 15:20 ` Peter Rajnoha
2014-01-22 9:02 ` Marius Vollmer
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=87wqhp4f7d.fsf@red.mvo.lan \
--to=marius.vollmer@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=prajnoha@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.