Re: [systemd-devel] [PATCH] logs-show: fix corrupt output with empty messages
On Thu, 2014-02-27 at 06:47 +0100, Zbigniew Jędrzejewski-Szmek wrote: Applied, though I changed the fix to simply print a newline. Just seems nicer this way. OK, though I would have added a return false; if doing it that way - now it somewhat non-obviously depends on the code below being a no-op in this case. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] RTC on BeagleBone Black or embedded platforms
Hello all First I'd like to express my gratitude for all the work that is being done with systemd. Until fairly recently I wasn't even aware that the project existed. I often just stay in my comfort zone and don't track recent advances... The boot speed is impressive and the cost of entry from my point of view isn't all that expensive. I've spent a few days reading and experimenting with systemd now and I'm sold. My biggest dilemma at this time right now is with the RTC. The BeagleBone Black does have a RTC and it gets assigned to /dev/rtc0. There is however now battery backup for this device. I've added a DS1307 with a battery to allow having a somewhat sane date maintained. Therein lies the dilemma, the code is only setup to access /dev/rtc. I'm sure that I can figure out with a (gasp) shell script or small c program how to set / get the date from the DS1307, it just seems that would be a very crude kludge. My question then is would it be considered to add options to the current timedated code that accepted device name and possibly path to the appropriate /etc/adjtime file? More information that may or may not have relevance. I am using this device as an NTP timeserver. The time sync is from a GPS module with PPS. Ideally this device will have little unpowered time. Real world experience tells me that even with 3 power inputs (Mains supply, solar, and Lith-io batt.) it will go down and will come back up way out of sync and need manual intervention. Distro: Debian testing (Jessie) systemd: version 204 kernel: Linux arm-ticktock 3.8.13-bone40.1 #1 SMP Thu Feb 20 21:12:57 EST 2014 armv7l GNU/Linux If this case is too much of an edge case to be considered I can understand that. I would suspect that will all the current embedded devices out there that I am not the only one that will hit this issue. Any help / pointers to RTFM gladly accepted I do believe that I've done my homework on this though. Thanks again for a nice project Mike ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RTC on BeagleBone Black or embedded platforms
On Thu, Feb 27, 2014 at 4:46 PM, Mike bellyac...@gmail.com wrote: My biggest dilemma at this time right now is with the RTC. The BeagleBone Black does have a RTC and it gets assigned to /dev/rtc0. There is however now battery backup for this device. Assuming you meant no? I've added a DS1307 with a battery to allow having a somewhat sane date maintained. Therein lies the dilemma, the code is only setup to access /dev/rtc. I'm sure that I can figure out with a (gasp) shell script or small c program how to set / get the date from the DS1307, it just seems that would be a very crude kludge. Can't you set the kernel config to use the new clock as the system rtc? It's a kernel config option. Can't you write a udev rule that creates /dev/rtc for your new clock? That should be picked up from userspace, but userspace does not do the initial sync from the hardware to the system, we only do that in the kernel so far. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RTC on BeagleBone Black or embedded platforms
On Thu, 27.02.14 10:46, Mike (bellyac...@gmail.com) wrote: Heya, My biggest dilemma at this time right now is with the RTC. The BeagleBone Black does have a RTC and it gets assigned to /dev/rtc0. There is however no battery backup for this device. I've added a Hmm, what's the point of such an RTC? I mean, Linux uses an RTC only to initialize the system clock from and then never looks at it again. But if the RTC has no battery it's entirely pointless to ever look at it, so what is an RTC good for that has no battery? DS1307 with a battery to allow having a somewhat sane date maintained. Therein lies the dilemma, the code is only setup to access /dev/rtc. I'm sure that I can figure out with a (gasp) shell script or small c program how to set / get the date from the DS1307, it just seems that would be a very crude kludge. If you have two RTCs one of which has no battery, why expose that to userspace at all? Can't you just disable that driver, and only use the working onen? My question then is would it be considered to add options to the current timedated code that accepted device name and possibly path to the appropriate /etc/adjtime file? It really sounds as if this is a local configuration problem of what is exposed by the kernel... Also note that PID will do the initial timezone bump for /dev/rtc only, too. Supporting an alternative RTC would also mean we'd ave t touch the earliest boot code. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] architecture: Add tilegx
Add Tilera's TILE-GX processor family support.
---
src/shared/architecture.c | 3 +++
src/shared/architecture.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/shared/architecture.c b/src/shared/architecture.c
index ceba492..eae82dc 100644
--- a/src/shared/architecture.c
+++ b/src/shared/architecture.c
@@ -112,6 +112,8 @@ Architecture uname_architecture(void) {
{ sh, ARCHITECTURE_SH },
#elif defined(__m68k__)
{ m68k, ARCHITECTURE_M68K },
+#elif defined(__tilegx__)
+{ tilegx, ARCHITECTURE_TILEGX },
#else
#error Please register your architecture here!
#endif
@@ -158,6 +160,7 @@ static const char *const
architecture_table[_ARCHITECTURE_MAX] = {
[ARCHITECTURE_SH] = sh,
[ARCHITECTURE_SH64] = sh64,
[ARCHITECTURE_M68K] = m68k,
+[ARCHITECTURE_TILEGX] = tilegx,
};
DEFINE_STRING_TABLE_LOOKUP(architecture, Architecture);
diff --git a/src/shared/architecture.h b/src/shared/architecture.h
index 3183645..e589a91 100644
--- a/src/shared/architecture.h
+++ b/src/shared/architecture.h
@@ -47,6 +47,7 @@ typedef enum Architecture {
ARCHITECTURE_SH,
ARCHITECTURE_SH64,
ARCHITECTURE_M68K,
+ARCHITECTURE_TILEGX,
_ARCHITECTURE_MAX,
_ARCHITECTURE_INVALID = -1
} Architecture;
@@ -107,6 +108,8 @@ Architecture uname_architecture(void);
# define native_architecture() ARCHITECTURE_SH
#elif defined(__m68k__)
# define native_architecture() ARCHITECTURE_M68K
+#elif defined(__tilegx__)
+# define native_architecture() ARCHITECTURE_TILEGX
#else
#error Please register your architecture here!
#endif
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support
Implements IPv4LL with respect to RFC 3927 (http://tools.ietf.org/rfc/rfc3927.txt) and integrates it with networkd. Majority of the IPv4LL state machine is taken from avahi (http://avahi.org/) project's autoip. IPv4LL can be enabled by IPv4LL=yes under [Network] section of .network file. IPv4LL works independent of DHCP but if DHCP lease is aquired, then LL address will be dropped. --- Makefile.am |7 +- TODO |5 + src/libsystemd-dhcp/ipv4ll-internal.h| 38 +++ src/libsystemd-dhcp/ipv4ll-network.c | 57 src/libsystemd-dhcp/ipv4ll-packet.c | 71 src/libsystemd-dhcp/sd-ipv4ll.c | 521 ++ src/libsystemd/sd-rtnl/rtnl-message.c| 14 + src/network/networkd-address.c |4 +- src/network/networkd-link.c | 312 -- src/network/networkd-network-gperf.gperf |1 + src/network/networkd-route.c | 85 + src/network/networkd.h |8 + src/systemd/sd-ipv4ll.h | 50 +++ src/systemd/sd-rtnl.h|1 + 14 files changed, 1143 insertions(+), 31 deletions(-) create mode 100644 src/libsystemd-dhcp/ipv4ll-internal.h create mode 100644 src/libsystemd-dhcp/ipv4ll-network.c create mode 100644 src/libsystemd-dhcp/ipv4ll-packet.c create mode 100644 src/libsystemd-dhcp/sd-ipv4ll.c create mode 100644 src/systemd/sd-ipv4ll.h diff --git a/Makefile.am b/Makefile.am index 25b48e5..ba69a17 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2409,7 +2409,12 @@ libsystemd_dhcp_la_SOURCES = \ src/libsystemd-dhcp/dhcp-option.c \ src/libsystemd-dhcp/dhcp-packet.c \ src/libsystemd-dhcp/dhcp-internal.h \ - src/libsystemd-dhcp/dhcp-protocol.h + src/libsystemd-dhcp/dhcp-protocol.h \ + src/systemd/sd-ipv4ll.h \ + src/libsystemd-dhcp/sd-ipv4ll.c \ + src/libsystemd-dhcp/ipv4ll-network.c \ + src/libsystemd-dhcp/ipv4ll-packet.c \ + src/libsystemd-dhcp/ipv4ll-internal.h libsystemd_dhcp_la_LIBADD = \ libsystemd-internal.la \ diff --git a/TODO b/TODO index 6cac3e2..711d2ad 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ Features: - add support for more DHCPv4 options (and, longer term, other kinds of dynamic config) - add proper initrd support (in particular generate .network/.link files based on /proc/cmdline) - add reduced [Link] support to .network files + - add IPv4LL tests (inspire by DHCP) + - add IPv4LL to man pages. Explain coexistance between DHCP + - add Scope= parsing option for [Network] + - change LL address generation and make it predictable like get_mac() (link-config.c) + - have smooth transition from LL to routable address, without disconnecting clients. External: diff --git a/src/libsystemd-dhcp/ipv4ll-internal.h b/src/libsystemd-dhcp/ipv4ll-internal.h new file mode 100644 index 000..fe5ef8e --- /dev/null +++ b/src/libsystemd-dhcp/ipv4ll-internal.h @@ -0,0 +1,38 @@ +/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/ + +#pragma once + +/*** + This file is part of systemd. + + Copyright (C) 2014 Axis Communications AB. All rights reserved. + + systemd is free software; you can redistribute it and/or modify it + under the terms of the GNU Lesser General Public License as published by + the Free Software Foundation; either version 2.1 of the License, or + (at your option) any later version. + + systemd is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public License + along with systemd; If not, see http://www.gnu.org/licenses/. +***/ + +#include netinet/if_ether.h + +#include sparse-endian.h +#include socket-util.h + +int arp_network_bind_raw_socket(int index, union sockaddr_union *link); +int arp_network_send_raw_socket(int fd, const union sockaddr_union *link, +const struct ether_arp *arp); + +void arp_packet_init(struct ether_arp *arp); +void arp_packet_probe(struct ether_arp *arp, be32_t pa, const struct ether_addr *ha); +void arp_packet_announcement(struct ether_arp *arp, be32_t pa, const struct ether_addr *ha); +int arp_packet_verify_headers(struct ether_arp *arp); + +#define log_ipv4ll(ll, fmt, ...) log_meta(LOG_DEBUG, __FILE__, __LINE__, __func__, IPv4LL: fmt, ##__VA_ARGS__) diff --git a/src/libsystemd-dhcp/ipv4ll-network.c b/src/libsystemd-dhcp/ipv4ll-network.c new file mode 100644 index 000..b325445 --- /dev/null +++ b/src/libsystemd-dhcp/ipv4ll-network.c @@ -0,0 +1,57 @@ +/*** + This file is part of systemd. + + Copyright (C) 2014 Axis Communications AB. All rights reserved. + + systemd is free software; you can redistribute it and/or
[systemd-devel] statically linking systemd-socket-proxyd
I see that despite --enable-static listed as a ./configure flag, it is not supported. Can we get a Makefile target for compiling the systemd-socket-proxyd as statically linked? For it to be portable for any guest container. Take care, vb pgpdy2yt5pm0C.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statically linking systemd-socket-proxyd
El 27/02/14 17:35, Vincent Batts escribió: I see that despite --enable-static listed as a ./configure flag, it is not supported. Can we get a Makefile target for compiling the systemd-socket-proxyd as statically linked? For it to be portable for any guest container. static linking will not offer portability. this is a myth. see http://www.akkadia.org/drepper/no_static_linking.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pcre in daemons
On Wed, 26.02.14 20:54, Thomas H.P. Andersen (pho...@gmail.com) wrote: The todo says: something pulls in pcre as shared object dependency into our daemons such as hostnamed Normal buiild: ldd ./systemd-hostnamed linux-vdso.so.1 = (0x7fff247bc000) libselinux.so.1 = /lib64/libselinux.so.1 (0x7f7ec47f7000) librt.so.1 = /lib64/librt.so.1 (0x7f7ec45ef000) libdl.so.2 = /lib64/libdl.so.2 (0x7f7ec43ea000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f7ec41cd000) libc.so.6 = /lib64/libc.so.6 (0x7f7ec3e0e000) /lib64/ld-linux-x86-64.so.2 (0x7f7ec4a2f000) libpcre.so.1 = /lib64/libpcre.so.1 (0x7f7ec3ba7000) liblzma.so.5 = /lib64/liblzma.so.5 (0x7f7ec3982000) With --disable-selinux: $ ldd ./systemd-hostnamed linux-vdso.so.1 = (0x7fff1a651000) librt.so.1 = /lib64/librt.so.1 (0x7f1c058d) libdl.so.2 = /lib64/libdl.so.2 (0x7f1c056cc000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f1c054ae000) libc.so.6 = /lib64/libc.so.6 (0x7f1c050ef000) /lib64/ld-linux-x86-64.so.2 (0x7f1c05aec000) Not sure what to do about that though... For some reason linking to libselinux has the result that libpcre is pulled in as direct dependency, too. i.e. for some reason libselinux seems to enforce ld's --copy-dt-needed-entries option when linking to it. I have the suspicion this is caused because libselinux uses gcc constructors/_init. Which is a pretty poor choice, of course, libselinux really shouldn't use gcc constructors. In fact, nobody should ever use gcc constructors... Also, if a library has gcc constructors it makes --as-needed useless on it, apparently. It's quite understandable: after all dropping the libs would result in different code to be executed, since just loading the libs already results in code execution in the library. So in order not to change behaviour ld exclude libraries with constructors from --as-needed... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pcre in daemons
On Wed, 26.02.14 16:22, Daniel J Walsh (dwa...@redhat.com) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/2014 03:05 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Feb 26, 2014 at 08:54:34PM +0100, Thomas H.P. Andersen wrote: The todo says: something pulls in pcre as shared object dependency into our daemons such as hostnamed Normal buiild: ldd ./systemd-hostnamed linux-vdso.so.1 = (0x7fff247bc000) libselinux.so.1 = /lib64/libselinux.so.1 (0x7f7ec47f7000) librt.so.1 = /lib64/librt.so.1 (0x7f7ec45ef000) libdl.so.2 = /lib64/libdl.so.2 (0x7f7ec43ea000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f7ec41cd000) libc.so.6 = /lib64/libc.so.6 (0x7f7ec3e0e000) /lib64/ld-linux-x86-64.so.2 (0x7f7ec4a2f000) libpcre.so.1 = /lib64/libpcre.so.1 (0x7f7ec3ba7000) liblzma.so.5 = /lib64/liblzma.so.5 (0x7f7ec3982000) It's a selinux problem (or not, if it actually uses pcre's). ldd /lib64/libselinux.so.1 linux-vdso.so.1 = (0x7fff58bfe000) libpcre.so.1 = /lib64/libpcre.so.1 (0x00380340) liblzma.so.5 = /lib64/liblzma.so.5 (0x0035d680) libdl.so.2 = /lib64/libdl.so.2 (0x0035d2c0) libc.so.6 = /lib64/libc.so.6 (0x0035d200) /lib64/ld-linux-x86-64.so.2 (0x0035d180) libpthread.so.0 = /lib64/libpthread.so.0 (0x0035d280) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel libselinux and systemd take advantage of pcre for speeding up the handling of reading in the labeling file. Not really. systemd doesn't use pcre at all, actually. It's only libselinux. And for some reason that is pulled into our binary as well... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statically linking systemd-socket-proxyd
On Thu, Feb 27, 2014 at 12:35 PM, Vincent Batts vba...@redhat.com wrote: Can we get a Makefile target for compiling the systemd-socket-proxyd as statically linked? For it to be portable for any guest container. I think that would be neat. While I wrote much of that proxy, I'm not versed well enough on linking and our toolchain to do static linking work myself. I'd happily review a patch, though. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] San Francisco Hackfest April 15th?
Heya! We are looking into organizing a systemd hackfest in San Francisco around th 15th of April, at the Pantheon offices. At least Kay and I will show up, but we were wondering regarding the precise date which day would work best for people who might want to join? Any suggestions, comments? (We'll be around for the GNOME West Coast hackfest as well as the RH summit, which brings us over there). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support
This is a lot of code, and this approach is largely obsoleted by link-local IPv6 addressing, which also has the benefits of being simpler, deterministic (at least with RFC 4862), and collision-proof. Both Apple [1] and Microsoft [2] prefer IPv6 link-local as the best practice. Is it really that important to support self-assigned IPv4? [1] https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/NetServices/Articles/about.html [2] https://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] San Francisco Hackfest April 15th?
On Thu, Feb 27, 2014 at 11:40:45PM +0100, Lennart Poettering wrote: Heya! We are looking into organizing a systemd hackfest in San Francisco around th 15th of April, at the Pantheon offices. At least Kay and I will show up, but we were wondering regarding the precise date which day would work best for people who might want to join? Any suggestions, comments? I'll try to be there. I have to be back by the 24th. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
I'll be attending the Linux Storage, Filesystem MM Summit in March. Are there any topics germane to systemd I should put on the agenda or discuss with other folks there? Things I have in mind so far: * Next steps for mount and automount units * That's it so far. I'm mostly attending for my company's FuseDAV/Valhalla work, but I'd like to effectively represent systemd as well. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
On Thu, 27.02.14 14:44, David Timothy Strauss (da...@davidstrauss.net) wrote: I'll be attending the Linux Storage, Filesystem MM Summit in March. Are there any topics germane to systemd I should put on the agenda or discuss with other folks there? Things I have in mind so far: * Next steps for mount and automount units * That's it so far. I'm mostly attending for my company's FuseDAV/Valhalla work, but I'd like to effectively represent systemd as well. Hmm, there are a couple of things on my wishlist: - quota for tmpfs - saner autofs elapse logic (no blocking ioctls...) - uuids for btrfs subvols - a umount (or maybe last-change) timestamp in the btrfs superblock, which we can use to initialize the system clock from if a machine lacks RTC or has a dead battery. Even better: a unified ioctl() to query this from all file systems the same way. - fanotify: accessible to unprivileged users - fanotify: events for renames - fanotify: pass info about open() flags to monitoring processes - fanotify: when getting getting a notification for close, actually get information whether the file was changed or not - an ioctl-based way to change FAT file system labels - cheaper xattrs. currently querying xattrs on most file systems is prohibitively slow, since it results in seeks and whatnot. Which has the result that pretty nobody uses them. One way to make things better would be to maybe expose in some fstat2() call a flag whether there even are xattrs, so that apps could check for that flag before actually trying to read them - An API to query the birthtime of files. ext234 actually stores that and keeps it up-to-date, but there's no API to get to this data - An fsetxattrat() call, so that race-free selinux relabelling can be done - a way to mark an entire tree of mounts read-only with one call. i.e. a working combination of MS_REC|MS_RDONLY - Allow creating read-only bind mounts in a single mount() invocation, instead of requiring two. Similar, a way to set the propagation settings for a mount when one creates it, rather than requiring two mount() invocations for that. - Swappiness control for individual pages via madvise() - volatile ranges - A better SIGBUS/SIGSEGV API (for accessing invalidated memory maps), that actually works for libraries. i.e. a sane way how libraries can register handlers for specific memory regions they maage. Currently there can only be one handler for the entire process which makes this totally unavailable for libraries, since they'd always step on each others toes. Probably hard one to get into the brains of kernel guys, since for them that is a userspace problem. Oh, and note that Al Viro dislikes systemd and particularly me with a passion. It's probably not good mentioning us in any discussion with him... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statically linking systemd-socket-proxyd
On Thu, 27.02.14 15:35, Vincent Batts (vba...@redhat.com) wrote: I see that despite --enable-static listed as a ./configure flag, it is not supported. Can we get a Makefile target for compiling the systemd-socket-proxyd as statically linked? For it to be portable for any guest container. As Cristian said, static linking is really a false holy grail... That said, the tool has exactly zero deps besides glibc. (where glibc in this definition consists of libpthread, librt, libc). Hence, when it comes to portability it gets pretty much as close to portability to various systems as it can get. Linux systems might vary greatly in the libraries they offer or have installed, but a glibc they all should have Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support
On Thu, 27.02.14 21:54, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:
Implements IPv4LL with respect to RFC 3927
(http://tools.ietf.org/rfc/rfc3927.txt) and integrates it
with networkd. Majority of the IPv4LL state machine is
taken from avahi (http://avahi.org/) project's autoip.
IPv4LL can be enabled by IPv4LL=yes under [Network]
section of .network file.
IPv4LL works independent of DHCP but if DHCP lease is
aquired, then LL address will be dropped.
Hmm, how is this hooked up in detail? i.e. when is the IPv4LL state
machine started? I think I'd like to see this started after a short
while when no DHCP response is seen, and immediately stopped as soon as
one is found later on. Or what are your ideas here? Tom?
I assume the IPv4ll state machine is started again if the DHCP leas runs
out and no DHCP wants to provide a new one?
How is this hooked up with the link beat? I mean, if we watch the link
beat and it changes, and we already have an ipv4ll address we probably
want to check for conflicts immediately?
If an IPv4LL address has been acquired, and then a DHCP server becomes
available, do we really want to drop the address entirely? At least for
IPv6 there's this concept of deprecated addresses for this purpose. I
am pretty sure that's actually available for IPv4 as well, so maybe we
should keep the ipv4ll adderss around and just mark it deprecated?
This would allow ongoing TCP conenctions to survive, but the kernel
wouldn't use the address as source address anymore.
I think IPv4LL would be a really valuable addition to networkd. But in
contrast to what we did with avahi-autoipd and how it was used by
NetworkManager I'd really make it so good that we can enable it by
default, so that it just works.
Some very superficial comments on the code (Tom and Patrik are probably
better folks to review this).
+ll-receive_message = sd_event_source_unref(ll-receive_message);
+if (ll-fd)
+close_nointr_nofail(ll-fd);
This looks wrong. You want to check = 0 here, since 0 is actually a
valid fd, and -1 is not...
+uint32_t a = 1;
+int i;
+
+for (i = 0; i ETH_ALEN; i++)
+a += ll-mac_addr.ether_addr_octet[i]*i;
+a = (a % 0xFE00) + 0x0100;
+addr = htonl(IPV4LL_NETWORK | (uint32_t) a);
Hmm, this hash function is probably not that great... We probably should
just use siphash here, we kind try to standardize on that...
+if (random_sec) {
+next_timeout += random_u32() % (random_sec * USEC_PER_SEC);
+}
Strictly speaking, this is evil, since it doesn't result in even
distribution. But then again, it doesn't really matter
Btw, please avoid extranous {} for single-line blocks like in the case
above. This isn't PHP after all!
Thanks for doing this work!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
On Feb 27, 2014, at 4:09 PM, Lennart Poettering lenn...@poettering.net wrote: - uuids for btrfs subvols btrfs subvol show pathtosubvolume It will show the subvol uuid, and if it's a snapshot it will also show the parent uuid. If you mean partitiontypeGUID so we have some idea what the purpose of these subvolumes is, like the unique partitiontypeGUID for home? Could be useful. Certainly there could be some additional metadata for tracking the relationship between many subvolumes as well as purpose. Possibly a snapshot family, that describes multiple subvolumes; and then use that information for a systemd mount job, it would make fstab mostly obsolete. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support
On Thu, 27.02.14 14:28, David Timothy Strauss (da...@davidstrauss.net) wrote: This is a lot of code, and this approach is largely obsoleted by link-local IPv6 addressing, which also has the benefits of being simpler, deterministic (at least with RFC 4862), and collision-proof. Both Apple [1] and Microsoft [2] prefer IPv6 link-local as the best practice. Is it really that important to support self-assigned IPv4? [1] https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/NetServices/Articles/about.html [2] https://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx Well, APIPA has been supported in OSes since a lot longer than IPv6 link-local addresses, for example in Windows 98... And I fear IPv4 is not going to die so soon... It might even be a useful thing for local containers since it might be faster than DHCPv4 is some cases, if people actually want IPv4 there. Maybe I am biased, because I wrote that IPv4ll implementation in Avahi a long time ago, but I am pretty sure this is something to support if we ever want to be a generic solution that speaks enough of these protocols to be comprehensively useful. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
On Thu, 27.02.14 17:06, Chris Murphy (li...@colorremedies.com) wrote: On Feb 27, 2014, at 4:09 PM, Lennart Poettering lenn...@poettering.net wrote: - uuids for btrfs subvols btrfs subvol show pathtosubvolume It will show the subvol uuid, and if it's a snapshot it will also show the parent uuid. If you mean partitiontypeGUID so we have some idea what the purpose of these subvolumes is, like the unique partitiontypeGUID for home? Could be useful. Certainly there could be some additional metadata for tracking the relationship between many subvolumes as well as purpose. Oh, sorry, yeah, i meant subvolume *type* UUIDs, indeed. i.e. like the partition type UUIDs that GPT exposes for every partition. And yupp, this is about discovering automatically where to mount what when just looking at a btrfs volume. Possibly a snapshot family, that describes multiple subvolumes; and then use that information for a systemd mount job, it would make fstab mostly obsolete. Instead of supporting too much flexibility I'd try to focus on collecting the subvolumes by a simple rule, for example: just take the first subvolumes with the right type uuids, or just take the oldest or the newest ones, or so... Anyway, sorry for the confusion! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
On Feb 27, 2014, at 5:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 27.02.14 17:06, Chris Murphy (li...@colorremedies.com) wrote: On Feb 27, 2014, at 4:09 PM, Lennart Poettering lenn...@poettering.net wrote: - uuids for btrfs subvols btrfs subvol show pathtosubvolume It will show the subvol uuid, and if it's a snapshot it will also show the parent uuid. If you mean partitiontypeGUID so we have some idea what the purpose of these subvolumes is, like the unique partitiontypeGUID for home? Could be useful. Certainly there could be some additional metadata for tracking the relationship between many subvolumes as well as purpose. Oh, sorry, yeah, i meant subvolume *type* UUIDs, indeed. i.e. like the partition type UUIDs that GPT exposes for every partition. And yupp, this is about discovering automatically where to mount what when just looking at a btrfs volume. Possibly a snapshot family, that describes multiple subvolumes; and then use that information for a systemd mount job, it would make fstab mostly obsolete. Instead of supporting too much flexibility I'd try to focus on collecting the subvolumes by a simple rule, for example: just take the first subvolumes with the right type uuids, or just take the oldest or the newest ones, or so… I think this gets really dangerous really fast if we're talking about a bunch of snapshots which would presumably inherit the parent's subvolumetypeGUID. Already on openSUSE by default with Btrfs systems snapper takes before and after snapshots before every system update so it quickly gets to hundreds of snapshots. On Btrfs there's no such thing as simple unless snapshots are proscribed. Otherwise it needs to tie specific snapshots together so they don't end up being mounted sync, like a the wrong /boot with a new kernel and old rootfs with the wrong version /lib/modules. Also it's not assumable that the newest or oldest of anything is the right thing to mount, because the user might have created a branch with snapshot. Further :-) arguably we shouldn't have a /home subvolume but rather user subvolumes to snapshot because users could independently snapshot and rollback their own home, that shouldn't affect other user's home. And even more esoteric but realistic examples exist. Possible the OSTree project is a better way to manage these semantics. It hides and manages all possible trees, it works on any file system, and can use LVM thinp or Btrfs snapshots (or reflinks) as an optimization where appropriate. But overall this is still a good discussion to explore at LSF. And for that matter, LVM LV's maybe need an LVtypeGUID to be equivalent to partitiontypeGUID and subvolumetypeGUID. I'd also suggest the OSTree project as topic. And if there's room for file system and security issues, I'm still rather curious about the possibility of separate trees (or snapshots) exposing stale binaries with known exploits. I started this thread ostensibly about btrfs snapshot questions, but it may also be relevant for OSTree snapshots. https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
On Thu, 27.02.14 17:47, Chris Murphy (li...@colorremedies.com) wrote: On Feb 27, 2014, at 5:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 27.02.14 17:06, Chris Murphy (li...@colorremedies.com) wrote: On Feb 27, 2014, at 4:09 PM, Lennart Poettering lenn...@poettering.net wrote: - uuids for btrfs subvols btrfs subvol show pathtosubvolume It will show the subvol uuid, and if it's a snapshot it will also show the parent uuid. If you mean partitiontypeGUID so we have some idea what the purpose of these subvolumes is, like the unique partitiontypeGUID for home? Could be useful. Certainly there could be some additional metadata for tracking the relationship between many subvolumes as well as purpose. Oh, sorry, yeah, i meant subvolume *type* UUIDs, indeed. i.e. like the partition type UUIDs that GPT exposes for every partition. And yupp, this is about discovering automatically where to mount what when just looking at a btrfs volume. Possibly a snapshot family, that describes multiple subvolumes; and then use that information for a systemd mount job, it would make fstab mostly obsolete. Instead of supporting too much flexibility I'd try to focus on collecting the subvolumes by a simple rule, for example: just take the first subvolumes with the right type uuids, or just take the oldest or the newest ones, or so… I think this gets really dangerous really fast if we're talking about a bunch of snapshots which would presumably inherit the parent's subvolumetypeGUID. Already on openSUSE by default with Btrfs systems snapper takes before and after snapshots before every system update so it quickly gets to hundreds of snapshots. On Btrfs there's no such thing as simple unless snapshots are proscribed. Otherwise it needs to tie specific snapshots together so they don't end up being mounted sync, like a the wrong /boot with a new kernel and old rootfs with the wrong version /lib/modules. Also it's not assumable that the newest or oldest of anything is the right thing to mount, because the user might have created a branch with snapshot. Well, this is precisely the set of reasons why we don't do GPT auto-discovery for /var either: we do not want to get into the risk of matching up versions that do not belong together. This isn't any different for btrfs either: we should simply not do this for /var. If people want to split off /var into their own subvol, then they are welcome, but they need to add an explicitly reference to it in /etc/fstab, as they always did. Further :-) arguably we shouldn't have a /home subvolume but rather user subvolumes to snapshot because users could independently snapshot and rollback their own home, that shouldn't affect other user's home. Precisely, that's why we do automatic discovery on GPT for /home, but not for /var. I think we should auto-discover the root subvol (from the initrd), and /home, and maybe /srv, but little else. And even more esoteric but realistic examples exist. Possible the OSTree project is a better way to manage these semantics. It hides and manages all possible trees, it works on any file system, and can use LVM thinp or Btrfs snapshots (or reflinks) as an optimization where appropriate. But overall this is still a good discussion to explore at LSF. And for that matter, LVM LV's maybe need an LVtypeGUID to be equivalent to partitiontypeGUID and subvolumetypeGUID. Well, from the systemd side we will not support LVM directly. They are welcome to add this, but I don't want to see a hook-up for this in systemd. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] architecture: Add tilegx
On Thu, 27.02.14 21:19, Henrik Grindal Bakken (h...@ifi.uio.no) wrote:
Applied! Thanks!
Add Tilera's TILE-GX processor family support.
---
src/shared/architecture.c | 3 +++
src/shared/architecture.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/shared/architecture.c b/src/shared/architecture.c
index ceba492..eae82dc 100644
--- a/src/shared/architecture.c
+++ b/src/shared/architecture.c
@@ -112,6 +112,8 @@ Architecture uname_architecture(void) {
{ sh, ARCHITECTURE_SH },
#elif defined(__m68k__)
{ m68k, ARCHITECTURE_M68K },
+#elif defined(__tilegx__)
+{ tilegx, ARCHITECTURE_TILEGX },
#else
#error Please register your architecture here!
#endif
@@ -158,6 +160,7 @@ static const char *const
architecture_table[_ARCHITECTURE_MAX] = {
[ARCHITECTURE_SH] = sh,
[ARCHITECTURE_SH64] = sh64,
[ARCHITECTURE_M68K] = m68k,
+[ARCHITECTURE_TILEGX] = tilegx,
};
DEFINE_STRING_TABLE_LOOKUP(architecture, Architecture);
diff --git a/src/shared/architecture.h b/src/shared/architecture.h
index 3183645..e589a91 100644
--- a/src/shared/architecture.h
+++ b/src/shared/architecture.h
@@ -47,6 +47,7 @@ typedef enum Architecture {
ARCHITECTURE_SH,
ARCHITECTURE_SH64,
ARCHITECTURE_M68K,
+ARCHITECTURE_TILEGX,
_ARCHITECTURE_MAX,
_ARCHITECTURE_INVALID = -1
} Architecture;
@@ -107,6 +108,8 @@ Architecture uname_architecture(void);
# define native_architecture() ARCHITECTURE_SH
#elif defined(__m68k__)
# define native_architecture() ARCHITECTURE_M68K
+#elif defined(__tilegx__)
+# define native_architecture() ARCHITECTURE_TILEGX
#else
#error Please register your architecture here!
#endif
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartLimitAction Feature
On Wed, 26.02.14 11:59, Usman (deser...@yahoo.com) wrote: Hi Guys, I am getting started with systemd and am looking for a particular answer. I know the config option StartLimitAction= will have a pre-set option to choose from. It either restarts the box or so. But I want to do something else as well. For example I want to execute a script when rate limit configured and burst level is hit. Is there a way to do that? Specifically I am looking for any message/event that I can see on dbus etc to know that tha restart rate limit is hit and we're restarting the box or just plainly stopping application (no more restarts). Any way to do that? You can invoke another service with OnFailure= as soon as your service fails. Then, you can pull the failure reason out of the original service via the bus and act on it. OnFailure=failure-handler@%p.servince and then in failure-handler@.service you take %i and use your own bus client or systemctl show -p to query the Result property which will tell you the reason the unit failed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On 26/02/2014 02:38, Lennart Poettering wrote: On Wed, 26.02.14 02:01, Jason A. Donenfeld (ja...@zx2c4.com) wrote: Upstream KDE patch is here: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp?format=diff Wow. Just wow. I am feeling tempted to just randomly change the version string exposed on the bus now, until they give that up. Whate else can I do than actually document that the string isn't stable? It is totally non-sensical to check for software versions the way KDE does it. We supply them with a call to check whether a certain operation is available (CanSuspend(), CanHibernate(), ...). They should just call that. It will tell them precisely whether the operation is not implemented in the code, or whether it is available on the hardware, and so on. But no, they decided to involve version checks... It looks like they check both systemd version and CanSuspend(), CanHibernate() results: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L229 Could it be for compatibility with older systemd releases? -- Timothée Ravier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support
On Thu, Feb 27, 2014 at 11:28 PM, David Timothy Strauss da...@davidstrauss.net wrote: This is a lot of code, and this approach is largely obsoleted by link-local IPv6 addressing, which also has the benefits of being simpler, deterministic (at least with RFC 4862), and collision-proof. Both Apple [1] and Microsoft [2] prefer IPv6 link-local as the best practice. Is it really that important to support self-assigned IPv4? While IPv6 link-local is nice, if the other devices on your local network only support ipv4 it won't do you much good. So I think this is something we definitely need to support out of the box. Moreover, the fact that people (Axis in this case) are still shipping products using this, probably means it will stay with us for quite some time. Cheers, Tom [1] https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/NetServices/Articles/about.html [2] https://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On Fri, 28.02.14 02:21, Timothée Ravier (sios...@gmail.com) wrote: On 26/02/2014 02:38, Lennart Poettering wrote: On Wed, 26.02.14 02:01, Jason A. Donenfeld (ja...@zx2c4.com) wrote: Upstream KDE patch is here: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp?format=diff Wow. Just wow. I am feeling tempted to just randomly change the version string exposed on the bus now, until they give that up. Whate else can I do than actually document that the string isn't stable? It is totally non-sensical to check for software versions the way KDE does it. We supply them with a call to check whether a certain operation is available (CanSuspend(), CanHibernate(), ...). They should just call that. It will tell them precisely whether the operation is not implemented in the code, or whether it is available on the hardware, and so on. But no, they decided to involve version checks... It looks like they check both systemd version and CanSuspend(), CanHibernate() results: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L229 Could it be for compatibility with older systemd releases? They should just invoke the methods. If they get org.freedesktop.DBus.Error.UnknownMethod, org.freedesktop.DBus.Error.UnknownObject or org.freedesktop.DBus.Error.UnknownInterface back they should assume that logind is too old and doesn't support the call. (Actually, to make this really robust, they should just treat any error like that). Check for features by trying to make use of them. Don't check for version numbers. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn: fix detection of missing /proc/self/loginuid
On Tue, 25.02.14 17:19, Tero Roponen (tero.ropo...@gmail.com) wrote:
Running 'systemd-nspawn -D /srv/Fedora/' gave me this error:
Failed to read /proc/self/loginuid: No such file or directory
Container Fedora failed with error code 1.
This patch fixes the problem.
Thanks!
Applied!
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 1a02935..e6f8ce7 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1349,7 +1349,7 @@ static int reset_audit_loginuid(void) {
return 0;
r = read_one_line_file(/proc/self/loginuid, p);
-if (r == -EEXIST)
+if (r == -ENOENT)
return 0;
if (r 0) {
log_error(Failed to read /proc/self/loginuid: %s,
strerror(-r));
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support
On Thu, Feb 27, 2014 at 09:54:17PM +0100, Umut Tezduyar Lindskog wrote:
Implements IPv4LL with respect to RFC 3927
(http://tools.ietf.org/rfc/rfc3927.txt) and integrates it
with networkd. Majority of the IPv4LL state machine is
taken from avahi (http://avahi.org/) project's autoip.
IPv4LL can be enabled by IPv4LL=yes under [Network]
section of .network file.
IPv4LL works independent of DHCP but if DHCP lease is
aquired, then LL address will be dropped.
Looks good.
Minor thoughts below:
+#define log_ipv4ll(ll, fmt, ...) log_meta(LOG_DEBUG, __FILE__, __LINE__,
__func__, IPv4LL: fmt, ##__VA_ARGS__)
I imagine that a user might want to control the log level of various
subsystems independently. It's nice that this is already a macro:
at some point we might want to turn the level into something configurable
on its own.
+ipv4ll_set_state (ll, IPV4LL_STATE_INIT, 1);
Indentation.
+if (ll-address) {
+do {
+uint32_t r = random_u32() 0x;
+addr = htonl(IPV4LL_NETWORK | r);
+} while (addr == ll-address || !(
+((ntohl(addr) IPV4LL_NETMASK) == IPV4LL_NETWORK)
+((ntohl(addr) 0xFF00) != 0x)
+((ntohl(addr) 0xFF00) != 0xFF00)));
Maybe one of the negations can be inverted:
} while (addr == ll-address ||
(ntohl(addr) IPV4LL_NETMASK) != IPV4LL_NETWORK ||
(ntohl(addr) 0xFF00) == 0x ||
(ntohl(addr) 0xFF00) == 0xFF00);
This seems more readable without all those parantheses.
+if (ll-state == IPV4LL_STATE_ANNOUNCING ||
+ll-state == IPV4LL_STATE_RUNNING) {
IN_SET(ll-state, IPV4LL_STATE_ANNOUNCING, IPV4LL_STATE_RUNNING)
+
+if (ipv4ll_arp_conflict(ll, in_packet)) {
+
+r = sd_event_get_now_monotonic(ll-event,
time_now);
+if (r 0)
+goto out;
+
+/* Defend address */
+if (time_now ll-defend_window) {
+ll-defend_window = time_now +
DEFEND_INTERVAL * USEC_PER_SEC;
+arp_packet_announcement(out_packet,
ll-address, ll-mac_addr);
+out_packet_ready = 1;
+} else
+conflicted = 1;
+}
+
+} else if (ll-state == IPV4LL_STATE_WAITING_PROBE ||
+ ll-state == IPV4LL_STATE_PROBING ||
+ ll-state == IPV4LL_STATE_WAITING_ANNOUNCE) {
IN_SET...
+
+conflicted = ipv4ll_arp_probe_conflict(ll,
in_packet);
+}
+
+if (conflicted) {
+log_ipv4ll(ll, CONFLICT);
Could we log more information here... With this we'd just have IPv4LL:
CONFLICT
in the logs. It would be nice to at least see the details of the conflicting
address
of something.
+r = ipv4ll_client_notify(ll, IPV4LL_EVENT_CONFLICT);
+ll-claimed_address = 0;
+
+/* Pick a new address */
+ll-address = ipv4ll_pick_address(ll);
+ll-conflict++;
+ll-defend_window = 0;
+ipv4ll_set_state(ll, IPV4LL_STATE_WAITING_PROBE, 1);
+
+if (ll-conflict = MAX_CONFLICTS) {
+log_ipv4ll (ll, MAX_CONFLICTS);
Whitespace.
+int sd_ipv4ll_start (sd_ipv4ll *ll) {
+int r;
+
+assert_return(ll, -EINVAL);
+assert_return(ll-event, -EINVAL);
+assert_return(ll-index 0, -EINVAL);
+assert_return(ll-state == IPV4LL_STATE_INIT, -EBUSY);
+
+r = arp_network_bind_raw_socket(ll-index, ll-link);
+
+if (r 0)
+goto error;
+
+ll-fd = r;
+ll-conflict = 0;
+ll-defend_window = 0;
+ll-claimed_address = 0;
+
+if (ll-address == 0)
+ll-address = ipv4ll_pick_address(ll);
+
+ipv4ll_set_state (ll, IPV4LL_STATE_INIT, 1);
+
+r = sd_event_add_io(ll-event, ll-receive_message, ll-fd,
+EPOLLIN, ipv4ll_receive_message, ll);
+if (r 0)
+goto error;
+
+r = sd_event_source_set_priority(ll-receive_message,
ll-event_priority);
+if (r 0)
+goto error;
+
+r = sd_event_add_monotonic(ll-event, ll-timer,
now(CLOCK_MONOTONIC), 0,
+ ipv4ll_timer, ll);
+
+if (r 0)
+goto error;
