On Fri, 21.03.14 21:58, Wouter Verhelst (w...@uter.be) wrote: > > > In addition, nbd-client needs to fork() and open() the /dev/nbdX device > > > to support partitioned NBD devices (due to a deadlock issue, that can't > > > be done from the initial NBD_DO_IT ioctl handling, so it is done in the > > > first open() instead). > > > > I don't follow here? > > I'm just trying to describe the full picture. I don't claim to > understand systemd fully (yet, anyway), and want to make sure I'm not > leaving things out that might be relevant -- even if they don't seem to > be at first glance. > > Point being, I suspect the nbdXpY devices might need to be depended on > (e.g., from whatever unit that mounts a file system), and then systemd > would need to know how to "create" them. That would be by connecting the > nbdX device, which then magically creates nbdXpY -- but only after the > fork() and open() of the device; this could complicate things in a > dependency/event-based system.
systemd will pick up all block devices (modulo the SYSTEMD_READY= thing), so if nbd-client does enough to trigger the creation of the partition devices, then systemd doesn't have to care for any specifics here, it should just work... > > Given your hint with the "pid" sysfs attribute, I think we should change > > the nbd rule to be more like the loop rule, and actually bind > > SYSTEMD_READY to the state in sysfs, rather than the type events > > last received. > > Yes, that sounds reasonable. Happy to take a bpatch for this, btw. Actually, I am kinda relying on this, since I can't test this... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
