On Fri, Mar 19, 2010 at 11:24 AM, Alasdair G Kergon <span dir="ltr"><<a href="mailto:agk@redhat.com">agk@redhat.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Mar 19, 2010 at 10:59:12AM -0400, David Zeuthen wrote:<br>
> I'd like to reiterate that it's actually not a problem that the sequence is<br>
>  - "add" uevent<br>
>  - device is not usable, access to the device fails gracefully<br>
>  - "change" uevent<br>
>  - device usable, blkid on the device etc. works<br>
> the point really is that you have to accept that there will exist<br>
> user space programs that does things on the device between<br>
> "add" and the initial "change" uevent.<br>
<br>
</div>It is a problem if both:<br>
    1) something attempts to open the devices in that window<br>
AND 2) we have no mechanism to wait for it to finish<br>
<br>
Also note that if it is permitted to run 'udevadm trigger' at<br>
any time that also causes a synchonisation problem here: our<br>
application code doesn't even know there is something conflicting<br>
that it needs to wait for.  [Even though we want to ignore ADD,<br>
we may still need to synchronise against it.]<br>
<br>
So again, the 'don't issue ADD until device is usable' offers a simple<br>
way of avoiding this class of problems.  </blockquote><div><br></div><div><div>But as Kay said it's a horrible horrible hack.</div><div><br></div><div><div>If you wanted to solve the problem kernel-side I'd expect you to</div>
<div>create a new subsytem for device-mapper (let's call it 'kdm') that</div><div>libdevmapper would talk to. Then you'd only present block device</div><div>objects exactly when the device-mapper side has been configured.</div>
<div><br></div><div>Then the flow of events could be something like this</div><div><br></div><div> - add device kdm-0  (subsys 'kdm')</div><div> - libdevmapper configures kdm-0</div><div> - add device dm-0 (subsys 'block')</div>
<div><br></div><div>but I don't know if this is better.</div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The 'private device<br>
attribute' we suggested offers another - all would be expected<br>
to respect a 'private' sysfs attribute.<br></blockquote><div><br></div><div>Sorry, but this is an even worse hack. Mandating that all of user</div><div>space (that is: past, present and future) needs to read some</div>
<div>random 'private' attribute in sysfs because of weird life-cycle</div><div>issues in the device-mapper implementation... that's not really</div><div>workable.</div><div><br></div><div>Anyway, I really don't think you can expect user space to behave</div>
<div>sanely so it's not really worth trying.</div><div><br></div><div>(I don't think you ever could expect user space to behave sanely,</div><div>but I'll note that it's an even bigger problem now that we have</div>
<div>powerful frameworks (such as udev) allowing people to run code</div><div>at device discovery time.... I mean, device-mapper have probably</div><div>been suffering from these issues from day 1 - it just wasn't visible</div>
<div>earlier on because we didn't have uevents...)</div><div><br></div><div>Thanks,</div><div>David</div><div><br></div></div>