FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 12-11-2007, 06:09 PM
Scott James Remnant
 
Default improve atomicity of device creation

On Tue, 2007-12-11 at 17:53 +0000, Alasdair G Kergon wrote:

> On Tue, Dec 11, 2007 at 05:40:28PM +0000, Scott James Remnant wrote:
> > 1) udev creates device node and sets permissions
> > 2) devmapper no-ops since it already exists
>
> ...because libdevmapper has no notion that something other than itself
> could have created it. That's a bug, but provided the proper udev
> integration isn't much longer in coming, I shan't bother to fix it.
>
That's ok no pressure on the patch, I just wanted to make sure that
we weren't carrying anything that hadn't at least been shown upstream to
see whether you wanted it or not.

Obviously we'd prefer the long-term solution, our patch is just a short
term one since we're already relying on udev for devmapper work today.

Scott
--
Scott James Remnant
scott@ubuntu.com
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-11-2007, 06:13 PM
Alasdair G Kergon
 
Default improve atomicity of device creation

On Tue, Dec 11, 2007 at 07:25:32PM +0100, Kay Sievers wrote:
> Should we create an additional new iocl to request the device node
> creation, or add that call to an existing one?

Currently we get an ADD from alloc_dev -> add_disk -> register_disk.
But the device is not usable until the dm resume ioctl, so ideally that
one should be ignored, and it's the CHANGE issued by dm resume that udev
should act upon. (That's not essential though - the /dev node can be
created in response to the ADD, but nothing in udev userspace should
attempt to open it until after the CHANGE is received.)

> Could it be that we want to pass more properties to the event, which are
> added as environment keys?

Don't think so - we'll be handing full control of ownership/permissions
over to udev.

Alasdair
--
agk@redhat.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 12-11-2007, 06:43 PM
Alasdair G Kergon
 
Default improve atomicity of device creation

On Tue, Dec 11, 2007 at 07:25:32PM +0100, Kay Sievers wrote:
> So we would need to strip the upper 32 bit of the numbers we see from
> udev, and handle the case where the 32 bit number wraps around.

Should be OK I think. Otherwise we can append a 64-bit field to the
struct - with care, this can be done without breaking compatibility.

Alasdair
--
agk@redhat.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 02:09 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org