From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Broz Subject: Re: [PATCH 1/3] Send KOBJ_ADD event after dm resume ioctl. Date: Fri, 19 Mar 2010 13:08:26 +0100 Message-ID: <4BA3693A.9030101@redhat.com> References: <1268920694-10960-1-git-send-email-mbroz@redhat.com> <4BA29CA4.9070000@redhat.com> <20100319090656.GR6379@soda.linbit> <4BA348B7.5070604@redhat.com> <4BA35C90.7000301@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Kay Sievers Cc: device-mapper development List-Id: dm-devel.ids On 03/19/2010 12:44 PM, Kay Sievers wrote: > On Fri, Mar 19, 2010 at 12:14, Milan Broz wrote: >> On 03/19/2010 11:16 AM, Kay Sievers wrote: >> Well. And what should happen if anyone generate >> artificial CHANGE event before the real first CHANGE event comes from >> subsystem? (yes, I am looking at you, OPTIONS+="watch" thing for example) > > We retrieve the device state and if it's not ready, we just exit. How? By scanning/opening it? Scan on uninitialised device can lock the device and break initialisation, "-EBUSY" - isn't it race? So all applications, which run some kind of configuration of device should expect that device can be randomly locked by udev rules... [Yes, it happens. I solved several problems in cryptsetup where various udev scans open and locks keyslot device. (Ignoring the fact that it contains key material, in this case it was not security problem - the material is still obfuscated.) These are now masked in udev rules, but I do not like this approach much.] > Yeah, usually it does not create any meta-information besides the > primary device node. Unfortunately it is not the DM/LVM etc case - we had always symlinks and long device names etc. Anyway, this name/uuid information is in sysfs now. But not the VG/LV symlinks info which is pure userspace abstraction... Milan -- mbroz@redhat.com