On Wed, 05.11.14 14:51, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> Colin Guthrie wrote on 03/11/14 08:02:
> > Zbigniew Jędrzejewski-Szmek wrote on 02/11/14 18:18:
> >> On Sun, Nov 02, 2014 at 02:04:20PM +0000, Colin Guthrie wrote:
> >>> This mirrors code in dbus.c when creating the private socket and
> >>> avoids error messages like:
> >>>
> >>> systemd[1353]: bind(/run/user/603/systemd/notify) failed: No such file or 
> >>> directory
> >>> systemd[1353]: Failed to fully start up daemon: No such file or directory
> >>
> >> Seems reasonable. But why not move the mkdir_parent_label() to the shared
> >> code path? Even if the dir is created elsewhere, it seems cleaner to ensure
> >> here that it is available.
> > 
> > Well, to be honest, I just copied the structure from dbus.c.
> > 
> > I can easily do as you suggest in both places if you think it's nicer. I
> > guess this would add two unnecessary stat()s (at least - not looked at
> > the mkdir... implementation!) on boot however, so might just be better
> > leaving it as is (not that that is a real problem practically speaking,
> > especially in tmpfs!).
> 
> Just pushed as is for now. I'm sure any moving of mkdir*() to common
> code path can come later (both here and in dbus.c) if it's deemed more
> readable and doesn't have a negative impact on performance (I'd expect
> it to be negligible, but I'm not an embedded guy)

It's not an inner loop. We it is usually called exactly once. We do
not optimize such cases for individual syscalls. Stuff that ends up in
inner loops is something to optimize, possibly.

Anyway, I moved the mkdir now to the common path. Not that it really
matters, but more because I wanted to cast the result to (void), in
order to make sure Coverity doesn't trip up over us ignoring the
return value from mkdir(). And while I was at it...

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to