<div class="gmail_quote">On Mon, May 9, 2011 at 12:43 PM, Lennart Poettering <span dir="ltr">&lt;<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">&gt; This means there are a large number of devices already known to the kernel</div><div class="im">
&gt; at the point that systemd starts, especially if you build the drivers into<br>
&gt; the kernel for those devices. It&#39;s possible to get going straight away with<br>
&gt; those devices. But relying on udevd tagging them means you end up waiting<br>
&gt; around for udevd to start, and worse! since udevd doesn&#39;t apply rules to<br>
&gt; existing devices on startup, you have to wait around for &quot;udevadm trigger&quot;<br>
&gt; to be run.<br>
<br>
</div>That&#39;s actually dead fast, and systemd picks up those devices as they<br>
show up. The trigger can hence finish after we already preceeded<br>
booting. In fact, with the new netlink actviation in newest udev and<br>
systemd we can start the trigger at the same time as udev itself.<br>
<br>
We cannot really mount file systems before their block devices have<br>
shown up and have been probed, and we exactly wait for that, and no<br>
longer. To do fsck/mount we need udev to have run for that device,<br>
there&#39;s no realistic way around that.<br>
<div class="im"><br></div></blockquote><div>It isn&#39;t &quot;dead fast&quot; enough.</div><div><br></div><div>The problem is that when you run udevadm trigger, it doesn&#39;t immediately spawn 700 processes to handle the events. So you end up with situations where input devices aren&#39;t available to X because the system is too busy probing for filesystems, or loading sound card drivers.</div>
<div><br></div><div>And we really *can* mount file systems before their block devices have been probed (they show up as soon as the driver&#39;s loaded). Actually the probing code is exactly the kind of code I would want to delay; filesystems can be mounted by GPT ids which doesn&#39;t require the expensive block device probing.</div>
<div><br></div><div>To my mind, we would want the filesystem mounted as soon as the kernel event arrives, whether or not udevd is running and whether or not udevadm trigger has been run.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">udev isn&#39;t just about symlinks. It&#39;s about perms and primarily about</div>
meta data, and a lot of other stuff too.<br>
<div class="im"><br></div></blockquote><div>perms are increasingly irrelevant due to ACLs, which your plans are moving to systemd, no?</div><div><br></div><div>Scott</div></div>