[systemd-devel] [PATCH 1/3] core: Add LISTEN_NAMES environment variable

[Lennart Poettering]

On Mon, 18.05.15 15:36, Krzysztof Opasiak (k.opasiak at samsung.com) wrote:

> Passing both type and path allows us to determine type of socket without any
> syscall. 

But how is that beneficial? THese sycalls are not slow, and this is
not perfoimance sensitive anyway...

> It is much faster as there is no context switch and consistent if we take
> both type and path from env instead of doing stat to determine type and then
> take path from env for comparsion. It doesn't add much more complexity but
> eliminates stat on fd in most functions so why not to do this?

Well, I disagree. It *does* add considerable complexity, especially
since it doesn't cover namespaced environments...

I am very sure $LISTEN_NAMES should only carry identifier strings
chosen by humans, and not duplicate what you can already do with
fstat() and /proc.

> >Hmm, why not just use the literl strings/chars wherever we need
> >them. It sounds needlessly complex to use constants for this, after
> >all we only use this within this one function...
> >
> >Also the last constant declares both a pointer and an array of string,
> >which appears unnecessary...
> 
> In may opinion this improves readability of the code. It simply indicates
> that you are looking for a separator and not for some unnamed semicolon. You
> don't need to look in documentation what does : means, as you see
> descriptive variable name.

Well, so far we preferred short code over unnecessary verbose code, as
that helps readability too...

> Well, not exactly it does a little bit more.
> 
> As use colons to separate paths in LISTEN_NAMES variable and we cannot
> guarantee that socket, fifo etc path doesn't contain colons (: is a valid
> path character in linux) we have to escape them. What this function does is
> merging all the paths, escape semicolons in paths using \ and place colons
> to separate paths. Example:

I'd simply dictate that the names included in $LISTEN_NAMES are not
allowed to contain colons. We should make this easy for
implementors. Escaping schemes are good if we need to be universal
but if we don't have to because we define our own namespace, then we
should avoid requiring them.

Lennart

-- 
Lennart Poettering, Red Hat