linux-kernel - Re: fastboot/async and initramfs: How am I supposed to know when devices are finished initializing?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Mar 2009 11:23:57 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Thomas Bächler <thomas@...hlinux.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: fastboot/async and initramfs: How am I supposed to know when 
	devices are finished initializing?

On Sun, Mar 29, 2009 at 11:06 AM, Kay Sievers <kay.sievers@...y.org> wrote:
> Assembling meta devices, or multi-volume devices should be triggered
> directly when the underlying devices show up. If auto-assembly (which
> kind of works today with md's --incremental) is properly implemented,
> you should still be able to just wait for the specified root device to
> show up...

Incremental assembly mostly works but it would be nice to have some
event to signal "proceed with degraded assembly because I do not think
any more disks are coming".  With the below patch my thought is that
we can have a rule that:
1/ checks if incremental assembly is in progress (to prevent adding
timeouts to the non-raid path)
2/ checks if the udev event queue is empty
3/ upon finding an idle queue pause to allow last chance discovery
4/ assuming the queue remains idle proceed with degraded assembly

Thoughts?  Perhaps (3) can be eliminated after loading scsi_wait_scan.

Thanks,
Dan

---ws damaged patch---
settle: allow --timeout=0 to test for "queue busy"

From: Dan Williams <dan.j.williams@...el.com>

Allow udevadm settle to be used as a "queue busy" detector.  For use in
a early raid discovery where we want to hold off committing to the
current list of disks while devices might still be arriving.

Signed-off-by: Dan Williams <dan.j.williams@...el.com>
---
 udev/udevadm-settle.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/udev/udevadm-settle.c b/udev/udevadm-settle.c
index 867bbed..2fa85a4 100644
--- a/udev/udevadm-settle.c
+++ b/udev/udevadm-settle.c
@@ -85,6 +85,9 @@ int udevadm_settle(struct udev *udev, int argc, char *argv[])
 		usleep(1000 * 1000 / LOOP_PER_SECOND);
 	}

+	if (!udev_queue_get_queue_is_empty(udev_queue))
+		rc = 1;
+
 	/* if we reached the timeout, print the list of remaining events */
 	if (loop <= 0) {
 		struct udev_list_entry *list_entry;
@@ -97,7 +100,6 @@ int udevadm_settle(struct udev *udev, int argc, char *argv[])
 				       udev_list_entry_get_name(list_entry),
 				       udev_list_entry_get_value(list_entry));
 		}
-		rc = 1;
 	}
 exit:
 	udev_queue_unref(udev_queue);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/