From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: udevd: serialize device chain event sequence
Date: Thu, 09 Dec 2004 10:06:32 +0000 [thread overview]
Message-ID: <20041209100632.GA7964@vrfy.org> (raw)
In-Reply-To: <20041208231335.GA6402@vrfy.org>
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
On Thu, Dec 09, 2004 at 09:18:28AM +0100, Kay Sievers wrote:
> On Wed, 2004-12-08 at 19:07 -0800, David Brownell wrote:
> > On Wednesday 08 December 2004 3:13 pm, Kay Sievers wrote:
> > > Any objections against the serialization of the event sequence of a
> > > chain of devices. Currently udevd delays only events for the same
> > > DEVPATH.
> > But the "add" for the underlying hardware (maybe USB) would
> > not be serialized.
>
> Right, just the stream of events for the /sys/devices/-device is
> serialized, but in another event sequence.
> > > The main motivation to do this is the program execution of the dev.d/
> > > and hotplug.d/ directory. If we don't wait for the parent event to exit,
> > > we can't be sure that the executed scripts are run in the right order.
> >
> > Could that argument apply to the underlying hardware, too?
>
> I will try it today and come back...
I like the idea. We now make sure that the sequence of events for a device
is serialized for every device chain and the class/block devices which have
a "device" link to a physical device are handled after the physical device
is fully populated and notified to userspace. It will only work this way on
kernels later than 2.6.10-rc1 cause it depends on the PHYSDEVPATH value from
the kernel.
Here is an example event sequence with unusual delays are simulated by placing a
script into the /etc/hotplug.d/ directory which sleeps for 3 seconds only for
the events of /block/sda and /devices/pci0000:00/0000:00:1d.1/usb3/3-1.
Thanks,
Kay
The device creation sequences while inserting an USB-stick in the order the
kernel forks the hotplug helper:
SEQNUM=1034
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1
SEQNUM=1035
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0
SEQNUM=1036
DEVPATH=/class/scsi_host/host3
PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host3
SEQNUM=1037
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host3/target3:0:0/3:0:0:0
SEQNUM=1038
DEVPATH=/block/sda
PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host3/target3:0:0/3:0:0:0
SEQNUM=1039
DEVPATH=/block/sda/sda1
PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host3/target3:0:0/3:0:0:0
SEQNUM=1040
DEVPATH=/class/scsi_device/3:0:0:0
PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host3/target3:0:0/3:0:0:0
SEQNUM=1041
DEVPATH=/class/scsi_generic/sg0
PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host3/target3:0:0/3:0:0:0
serialized sequence visible to hotplug.d/ programs with udevsend as the hotplug helper:
SEQNUM=1034
delay seq 1035, cause seq 1034 is still running (serialize /sys/devives/ chain)
SEQNUM=1035
delay seq 1036, cause seq 1034 is still running (wait for PHYSDEVPATH)
SEQNUM=1036
SEQNUM=1037
SEQNUM=1040
SEQNUM=1041
SEQNUM=1038
delay seq 1039, cause seq 1038 is still running (serialize /block/* chain)
SEQNUM=1039
[-- Attachment #2: udevd-serialize-event-sequence-02.patch --]
[-- Type: text/plain, Size: 2689 bytes --]
===== udevd.8 1.10 vs edited =====
--- 1.10/udevd.8 2004-11-28 05:41:14 +01:00
+++ edited/udevd.8 2004-12-09 01:18:36 +01:00
@@ -28,8 +28,6 @@
.B udevd
receives the events from
.B udevsend
-which is called by
-.BR hotplug (8).
If
.B udevd
isn't already running,
===== udevd.c 1.53 vs edited =====
--- 1.53/udevd.c 2004-11-28 05:56:22 +01:00
+++ edited/udevd.c 2004-12-09 09:58:07 +01:00
@@ -151,22 +151,40 @@
}
}
-/* returns already running task with devpath */
+/* returns still running task for the same event sequence */
static struct hotplug_msg *running_with_devpath(struct hotplug_msg *msg)
{
struct hotplug_msg *loop_msg;
+ int i;
+
list_for_each_entry(loop_msg, &running_list, list) {
if (loop_msg->devpath == NULL || msg->devpath == NULL)
continue;
- if (strcmp(loop_msg->devpath, msg->devpath) == 0)
- return loop_msg;
+ /* is a parent or child device event still running */
+ for (i = 0; i < DEVPATH_SIZE; i++) {
+ if (loop_msg->devpath[i] == '\0' || msg->devpath[i] == '\0')
+ return loop_msg;
+
+ if (loop_msg->devpath[i] != msg->devpath[i])
+ break;
+ }
+
+ /* is the physical device event still running on an add sequence */
+ if (msg->physdevpath && msg->action && strcmp(msg->action, "add") == 0)
+ for (i = 0; i < DEVPATH_SIZE; i++) {
+ if (loop_msg->devpath[i] == '\0' || msg->physdevpath[i] == '\0')
+ return loop_msg;
+
+ if (loop_msg->devpath[i] != msg->physdevpath[i])
+ break;
+ }
}
return NULL;
}
-/* exec queue management routine executes the events and delays events for the same devpath */
+/* exec queue management routine executes the events and serializes events in the same sequence */
static void exec_queue_manager(void)
{
struct hotplug_msg *loop_msg;
@@ -181,8 +199,8 @@
udev_run(loop_msg);
dbg("moved seq %llu to running list", loop_msg->seqnum);
} else {
- dbg("delay seq %llu, cause seq %llu already working on '%s'",
- loop_msg->seqnum, msg->seqnum, msg->devpath);
+ dbg("delay seq %llu (%s), cause seq %llu (%s) is still running",
+ loop_msg->seqnum, loop_msg->devpath, msg->seqnum, msg->devpath);
}
}
}
@@ -314,6 +332,9 @@
if (strncmp(key, "SEQNUM=", 7) == 0)
msg->seqnum = strtoull(&key[7], NULL, 10);
+
+ if (strncmp(key, "PHYSDEVPATH=", 12) == 0)
+ msg->physdevpath = &key[12];
}
msg->envp[i++] = "MANAGED_EVENT=1";
msg->envp[i] = NULL;
===== udevd.h 1.15 vs edited =====
--- 1.15/udevd.h 2004-11-22 22:14:20 +01:00
+++ edited/udevd.h 2004-12-09 09:20:40 +01:00
@@ -47,6 +47,7 @@
char *devpath;
char *subsystem;
unsigned long long seqnum;
+ char *physdevpath;
char *envp[HOTPLUG_NUM_ENVP+1];
char envbuf[];
};
prev parent reply other threads:[~2004-12-09 10:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-08 23:13 udevd: serialize device chain event sequence Kay Sievers
2004-12-09 3:07 ` David Brownell
2004-12-09 8:18 ` Kay Sievers
2004-12-09 10:06 ` Kay Sievers [this message]
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=20041209100632.GA7964@vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).