[systemd-devel] [v3 3/4] add rpmvercmp()

2015-02-27 Thread Shawn Landden
---
 Makefile.am|   2 +
 src/shared/rpmvercmp.c | 122 +
 src/shared/rpmvercmp.h |  14 ++
 3 files changed, 138 insertions(+)
 create mode 100644 src/shared/rpmvercmp.c
 create mode 100644 src/shared/rpmvercmp.h

diff --git a/Makefile.am b/Makefile.am
index e77a242..bba5353 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -902,6 +902,8 @@ libsystemd_shared_la_SOURCES = \
src/shared/nss-util.h \
src/shared/verbs.c \
src/shared/verbs.h \
+   src/shared/rpmvercmp.c \
+   src/shared/rpmvercmp.h \
src/shared/sigbus.c \
src/shared/sigbus.h \
src/shared/build.h \
diff --git a/src/shared/rpmvercmp.c b/src/shared/rpmvercmp.c
new file mode 100644
index 000..c69c2e3
--- /dev/null
+++ b/src/shared/rpmvercmp.c
@@ -0,0 +1,122 @@
+/* From rpm (Library GPLv2+, which is compatible with LGPLv2.1+)
+ * git://rpm.org/rpm.git
+ */
+
+#include 
+#include 
+#include 
+
+#include "util.h"
+#include "rpmvercmp.h"
+
+/* compare alpha and numeric segments of two versions */
+/* return 1: a is newer than b */
+/*0: a and b are the same version */
+/*   -1: b is newer than a */
+int rpmvercmp(const char * a, const char * b)
+{
+/* easy comparison to see if versions are identical */
+if (streq_ptr(a, b)) return 0;
+
+char oldch1, oldch2;
+char abuf[strlen(a)+1], bbuf[strlen(b)+1];
+char *str1 = abuf, *str2 = bbuf;
+char * one, * two;
+int rc;
+int isnum;
+
+strcpy(str1, a);
+strcpy(str2, b);
+
+one = str1;
+two = str2;
+
+/* loop through each version segment of str1 and str2 and compare them */
+while (*one || *two) {
+   while (*one && !isalnum(*one) && *one != '~') one++;
+   while (*two && !isalnum(*two) && *two != '~') two++;
+
+   /* handle the tilde separator, it sorts before everything else */
+   if (*one == '~' || *two == '~') {
+   if (*one != '~') return 1;
+   if (*two != '~') return -1;
+   one++;
+   two++;
+   continue;
+   }
+
+   /* If we ran to the end of either, we are finished with the loop */
+   if (!(*one && *two)) break;
+
+   str1 = one;
+   str2 = two;
+
+   /* grab first completely alpha or completely numeric segment */
+   /* leave one and two pointing to the start of the alpha or numeric */
+   /* segment and walk str1 and str2 to end of segment */
+   if (isdigit(*str1)) {
+   while (*str1 && isdigit(*str1)) str1++;
+   while (*str2 && isdigit(*str2)) str2++;
+   isnum = 1;
+   } else {
+   while (*str1 && isalpha(*str1)) str1++;
+   while (*str2 && isalpha(*str2)) str2++;
+   isnum = 0;
+   }
+
+   /* save character at the end of the alpha or numeric segment */
+   /* so that they can be restored after the comparison */
+   oldch1 = *str1;
+   *str1 = '\0';
+   oldch2 = *str2;
+   *str2 = '\0';
+
+   /* this cannot happen, as we previously tested to make sure that */
+   /* the first string has a non-null segment */
+   if (one == str1) return -1; /* arbitrary */
+
+   /* take care of the case where the two version segments are */
+   /* different types: one numeric, the other alpha (i.e. empty) */
+   /* numeric segments are always newer than alpha segments */
+   /* XXX See patch #60884 (and details) from bugzilla #50977. */
+   if (two == str2) return (isnum ? 1 : -1);
+
+   if (isnum) {
+   size_t onelen, twolen;
+   /* this used to be done by converting the digit segments */
+   /* to ints using atoi() - it's changed because long  */
+   /* digit segments can overflow an int - this should fix that. */
+
+   /* throw away any leading zeros - it's a number, right? */
+   while (*one == '0') one++;
+   while (*two == '0') two++;
+
+   /* whichever number has more digits wins */
+   onelen = strlen(one);
+   twolen = strlen(two);
+   if (onelen > twolen) return 1;
+   if (twolen > onelen) return -1;
+   }
+
+   /* strcmp will return which one is greater - even if the two */
+   /* segments are alpha or if they are numeric.  don't return  */
+   /* if they are equal because there might be more segments to */
+   /* compare */
+   rc = strcmp(one, two);
+   if (rc) return (rc < 1 ? -1 : 1);
+
+   /* restore character that was replaced by null above */
+   *str1 = oldch1;
+   one = str1;
+   *str2 = oldch2;
+   two = str2;
+}
+
+/* this catches the case where all numeric and alpha segments have */
+/* compared identically but the segment sepparating characters were */
+/* different */
+if ((!*one) && (!*two)) return 0;
+
+/* whichever version still has characters left over wins */
+if (!*one) return -1; else return 1;
+}
diff --git a/src/shared/r

[systemd-devel] [v3 4/4] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily

2015-02-27 Thread Shawn Landden
Still use helper when Xen Dom0, to avoid duplicating some hairy code.

I think the rbtree version was far more understandable as greedy_realloc0()
is very messy to do correctly.

Future: generate BootLoaderSpec files for other kernel install locations

v2: support specifying the kernel version
support appending to the kernel cmdline
some docs
support double force with kexec
allow rpmvercmp() to compare against NULL
v3: fix append kernel cmdline where no kernel version given
v4: remove rbtree
respond to review
Take fopenat() from lsof
---
 Makefile.am   |   4 +-
 TODO  |   3 -
 man/systemctl.xml |  15 ++-
 src/core/shutdown.c   |  28 --
 src/shared/fileio.c   |  59 
 src/shared/fileio.h   |   2 +
 src/shared/missing.h  |  11 +++
 src/shared/rpmvercmp.c|  12 ++-
 src/shared/strv.c |   9 +-
 src/systemctl/bootspec.c  | 230 ++
 src/systemctl/bootspec.h  |  51 ++
 src/systemctl/systemctl.c |  57 +++-
 12 files changed, 459 insertions(+), 22 deletions(-)
 create mode 100644 src/systemctl/bootspec.c
 create mode 100644 src/systemctl/bootspec.h

diff --git a/Makefile.am b/Makefile.am
index bba5353..4285146 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2742,7 +2742,9 @@ systemd_escape_LDADD = \
 
 # -
 systemctl_SOURCES = \
-   src/systemctl/systemctl.c
+   src/systemctl/systemctl.c \
+   src/systemctl/bootspec.c \
+   src/systemctl/bootspec.h
 
 systemctl_LDADD = \
libsystemd-units.la \
diff --git a/TODO b/TODO
index 1f5bfaa..15b0c82 100644
--- a/TODO
+++ b/TODO
@@ -76,9 +76,6 @@ Features:
 * maybe introduce WantsMountsFor=? Usecase:
   http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
 
-* rework kexec logic to use new kexec_file_load() syscall, so that we
-  don't have to call kexec tool anymore.
-
 * The udev blkid built-in should expose a property that reflects
   whether media was sensed in USB CF/SD card readers. This should then
   be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 338c1d3..c550339 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -607,6 +607,15 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 
 
 
+  list-kernels
+
+  
+List kernels ordered by version.
+
+  
+
+
+
   start 
PATTERN...
 
   
@@ -1550,7 +1559,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 
 
 
-  kexec
+  kexec 
VERSIONKERNEL-ARG...
 
   
 Shut down and reboot the system via kexec. This is
@@ -1560,6 +1569,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 services is skipped, however all processes are killed and
 all file systems are unmounted or mounted read-only,
 immediately followed by the reboot.
+
+Also allows specifying the version and optionally
+extra kernel parameters to append. If no version is specified
+then the most recent kernel is booted.
   
 
 
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 70a461e..a3d5393 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
   along with systemd; If not, see .
 ***/
 
+#include 
 #include 
 #include 
 #include 
@@ -179,9 +180,13 @@ int main(int argc, char *argv[]) {
 cmd = RB_POWER_OFF;
 else if (streq(arg_verb, "halt"))
 cmd = RB_HALT_SYSTEM;
-else if (streq(arg_verb, "kexec"))
-cmd = LINUX_REBOOT_CMD_KEXEC;
-else {
+else if (streq(arg_verb, "kexec")) {
+if (in_container) {
+log_warning("Can't kexec from container. 
Rebooting???");
+cmd = RB_AUTOBOOT;
+} else
+cmd = LINUX_REBOOT_CMD_KEXEC;
+} else {
 r = -EINVAL;
 log_error("Unknown action '%s'.", arg_verb);
 goto error;
@@ -200,8 +205,6 @@ int main(int argc, char *argv[]) {
 log_info("Sending SIGKILL to remaining processes...");
 broadcast_signal(SIGKILL, true, false);
 
-in_container = detect_container(NULL) > 0;
-
 need_umount = !in_container;
 need_swapoff = !in_container;
 need_loop_detach = !in_container;
@@ -341,11 +344,14 @@ int main(int argc, char *argv[]) {
 
 case LINUX_REBOOT_CMD_KEXEC:
 
-if (!in_container) {
-/* We cheat and exec kexec to avoid doing all its work 
*/
-pid_t pid;
+log_info("Reboo

[systemd-devel] [v3 2/4] update TODO

2015-02-27 Thread Shawn Landden
---
 TODO | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/TODO b/TODO
index e8e4800..1f5bfaa 100644
--- a/TODO
+++ b/TODO
@@ -32,6 +32,8 @@ External:
 * When lz4 gets an API for lz4 command output, make use of it to
   compress coredumps in a way compatible with /usr/bin/lz4.
 
+* Fix emacs for Lennart so we can get rid of the Makefile hack littering git
+
 Features:
 
 * When logging about multiple units (stopping BoundTo units, conflicts, etc.),
-- 
2.2.1.209.g41e5f3a

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [v3 1/4] man: these binaries are internal APIs

2015-02-27 Thread Shawn Landden
---
 man/systemd-halt.service.xml  | 1 -
 man/systemd-shutdownd.service.xml | 1 -
 man/systemd-suspend.service.xml   | 1 -
 3 files changed, 3 deletions(-)

diff --git a/man/systemd-halt.service.xml b/man/systemd-halt.service.xml
index c94e2a1..7e7f8f2 100644
--- a/man/systemd-halt.service.xml
+++ b/man/systemd-halt.service.xml
@@ -56,7 +56,6 @@
 systemd-poweroff.service
 systemd-reboot.service
 systemd-kexec.service
-/usr/lib/systemd/systemd-shutdown
   
 
   
diff --git a/man/systemd-shutdownd.service.xml 
b/man/systemd-shutdownd.service.xml
index 756949c..051d2ab 100644
--- a/man/systemd-shutdownd.service.xml
+++ b/man/systemd-shutdownd.service.xml
@@ -52,7 +52,6 @@
   
 systemd-shutdownd.service
 systemd-shutdownd.socket
-/usr/lib/systemd/systemd-shutdownd
   
 
   
diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml
index a8beb86..8e3df5f 100644
--- a/man/systemd-suspend.service.xml
+++ b/man/systemd-suspend.service.xml
@@ -56,7 +56,6 @@
 systemd-suspend.service
 systemd-hibernate.service
 systemd-hybrid-sleep.service
-/usr/lib/systemd/system-sleep
   
 
   
-- 
2.2.1.209.g41e5f3a

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [v1] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily

2015-02-27 Thread Shawn Landden
On Thu, Feb 26, 2015 at 12:04 AM, Jan Janssen  wrote:

> Shawn Landden  churchofgit.com> writes:
>
> >  void strv_free(char **l) {
> > -strv_clear(l);
> > +char **k;
> > +
> > +if (!l)
> > +return;
> > +
> > +for (k = l; *k; k++)
> > +free(*k);
> > +
> >  free(l);
> >  }
> What are you trying to achieve here? I see no point in optimizing out the
> *l
> = NULL from strv_clear.
>
> > +entry->linux_loc  = l + strspn(l,
> WHITESPACE);
> > +else if ((l = startswith(m, "initrd ")))
> > +entry->initrd = l + strspn(l,
> WHITESPACE);
> You need to support more than one initrd per kernel, see
> https://wiki.archlinux.org/index.php/Microcode for why. Also, I am pretty
> sure you can have a initrd=/path/to/initrd in the kernel options entry.
> Since the efi bootloader just appends each given initrd to the kernel
> command line.
>
I can't support more than one initrd per kernel with the kexec_file_load()
syscall, and if initrd on the commandline works, then it will still work
with this patch, so i don't need to change anything.

>
>
> All in all I am wondering why you need a rbtree for all this in the first
> place? A simple hashmap should do just fine.
>
> Also, you're not taking multi-boot into account (the machine-id field).
> You're just discriminating based on the kernel version, but different
> installations could have the same version field.
>
fixed by testing that the machine-id is the same (I forgot this part of the
spec thanks). Is there anyway I should save defaults? Is there anything in
the spec that is missing? Perhaps it should specify how to save last-boot.

>
> Jan
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 

---
Shawn Landden
ChurchOfGit.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] sd_id128_equal borked

2015-02-27 Thread Shawn Landden
_sd_pure_ static inline int sd_id128_equal(sd_id128_t a, sd_id128_t b) {
return memcmp(&a, &b, 16) == 0;
}

this should either be return memcmp(&a, &b, 16);
or return bool

-- 

---
Shawn Landden
ChurchOfGit.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] bootctl SIGSEGV

2015-02-27 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Feb 27, 2015 at 11:19:25PM +0200, Oleksii Shevchuk wrote:
> Program received signal SIGSEGV, Segmentation fault.
> bootctl_main.2553 (argc=, argv=) at
> /tmp/portage/sys-apps/systemd-/work/systemd-/src/boot/bootctl.c:1333
> 1333efi_tilt_backslashes(loader_path);
> (gdb) bt
> #0  bootctl_main.2553 (argc=, argv=) at
> /tmp/portage/sys-apps/systemd-/work/systemd-/src/boot/bootctl.c:1333
> #1  0x7e25 in main (argc=, argv=)
> at
> /tmp/portage/sys-apps/systemd-/work/systemd-/src/boot/bootctl.c:1404
> (gdb)
Should be fixed with 1a1db450e5.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-02-27 Thread Ivan Shapovalov
On 2015-02-27 at 22:25 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Feb 25, 2015 at 09:40:23PM +0300, Ivan Shapovalov wrote:
> > Because the order of coldplugging is not defined, we can reference a
> > not-yet-coldplugged unit and read its state while it has not yet been
> > set to a meaningful value.
> > 
> > This way, already active units may get started again.
> > 
> > We fix this by deferring such actions until all units have been at least
> > somehow coldplugged.
> > 
> > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=88401
> > ---
> > 
> > v2: set waiting state on path/timer units after deferring the actual 
> > coldplug,
> > so that we won't run into the exactly same problem during processing the
> > deferred entries.
> This looks good. I seems to be the correct thing to do independently of the
> idea to split device states into three with the new pending state.
> Let's see what Lennart thinks though.

Hmm.. This does not relate to the ongoing discussion about adding a
third state for .device units. This is about coldplugging .path
and .timer units during reloads.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-02-27 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Feb 25, 2015 at 09:40:23PM +0300, Ivan Shapovalov wrote:
> Because the order of coldplugging is not defined, we can reference a
> not-yet-coldplugged unit and read its state while it has not yet been
> set to a meaningful value.
> 
> This way, already active units may get started again.
> 
> We fix this by deferring such actions until all units have been at least
> somehow coldplugged.
> 
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=88401
> ---
> 
> v2: set waiting state on path/timer units after deferring the actual coldplug,
> so that we won't run into the exactly same problem during processing the
> deferred entries.
This looks good. I seems to be the correct thing to do independently of the
idea to split device states into three with the new pending state.
Let's see what Lennart thinks though.

Zbyszek


> 
>  src/core/automount.c |  2 +-
>  src/core/busname.c   |  2 +-
>  src/core/device.c|  2 +-
>  src/core/manager.c   | 33 -
>  src/core/mount.c |  2 +-
>  src/core/path.c  | 14 ++
>  src/core/scope.c |  2 +-
>  src/core/service.c   |  2 +-
>  src/core/slice.c |  2 +-
>  src/core/snapshot.c  |  2 +-
>  src/core/socket.c|  2 +-
>  src/core/swap.c  |  2 +-
>  src/core/target.c|  2 +-
>  src/core/timer.c | 14 ++
>  src/core/unit.c  | 25 -
>  src/core/unit.h  | 12 +---
>  16 files changed, 88 insertions(+), 32 deletions(-)
> 
> diff --git a/src/core/automount.c b/src/core/automount.c
> index 4a509ef..0539fbb 100644
> --- a/src/core/automount.c
> +++ b/src/core/automount.c
> @@ -233,7 +233,7 @@ static void automount_set_state(Automount *a, 
> AutomountState state) {
>  unit_notify(UNIT(a), state_translation_table[old_state], 
> state_translation_table[state], true);
>  }
>  
> -static int automount_coldplug(Unit *u) {
> +static int automount_coldplug(Unit *u, Hashmap *deferred_work) {
>  Automount *a = AUTOMOUNT(u);
>  int r;
>  
> diff --git a/src/core/busname.c b/src/core/busname.c
> index 1d77292..43d7607 100644
> --- a/src/core/busname.c
> +++ b/src/core/busname.c
> @@ -335,7 +335,7 @@ static void busname_set_state(BusName *n, BusNameState 
> state) {
>  unit_notify(UNIT(n), state_translation_table[old_state], 
> state_translation_table[state], true);
>  }
>  
> -static int busname_coldplug(Unit *u) {
> +static int busname_coldplug(Unit *u, Hashmap *deferred_work) {
>  BusName *n = BUSNAME(u);
>  int r;
>  
> diff --git a/src/core/device.c b/src/core/device.c
> index 2d983cc..70c2233 100644
> --- a/src/core/device.c
> +++ b/src/core/device.c
> @@ -104,7 +104,7 @@ static void device_set_state(Device *d, DeviceState 
> state) {
>  unit_notify(UNIT(d), state_translation_table[old_state], 
> state_translation_table[state], true);
>  }
>  
> -static int device_coldplug(Unit *u) {
> +static int device_coldplug(Unit *u, Hashmap *deferred_work) {
>  Device *d = DEVICE(u);
>  
>  assert(d);
> diff --git a/src/core/manager.c b/src/core/manager.c
> index 79a9d54..239c8bb 100644
> --- a/src/core/manager.c
> +++ b/src/core/manager.c
> @@ -975,8 +975,29 @@ static int manager_coldplug(Manager *m) {
>  Unit *u;
>  char *k;
>  
> +/*
> + * Some unit types tend to spawn jobs or check other units' state
> + * during coldplug. This is wrong because it is undefined whether the
> + * units in question have been already coldplugged (i. e. their state
> + * restored). This way, we can easily re-start an already started 
> unit
> + * or otherwise make a wrong decision based on the unit's state.
> + *
> + * Solve this by providing a way for coldplug functions to defer
> + * such actions until after all units have been coldplugged.
> + *
> + * We store Unit* -> int(*)(Unit*).
> + *
> + * https://bugs.freedesktop.org/show_bug.cgi?id=88401
> + */
> +_cleanup_hashmap_free_ Hashmap *deferred_work = NULL;
> +int(*proc)(Unit*);
> +
>  assert(m);
>  
> +deferred_work = hashmap_new(&trivial_hash_ops);
> +if (!deferred_work)
> +return -ENOMEM;
> +
>  /* Then, let's set up their initial state. */
>  HASHMAP_FOREACH_KEY(u, k, m->units, i) {
>  int q;
> @@ -985,7 +1006,17 @@ static int manager_coldplug(Manager *m) {
>  if (u->id != k)
>  continue;
>  
> -q = unit_coldplug(u);
> +q = unit_coldplug(u, deferred_work);
> +if (q < 0)
> +r = q;
> +}
> +
> +/* After coldplugging and setting up initial state of the units,
> + * let's perform operations which spawn jobs or query units' state. 
> */
> +HASHMAP_FOREACH_KEY(proc, u, deferred_work, i) {
> +int 

Re: [systemd-devel] [PATCH] user-sessions: move into own subdir and build independently of logind

2015-02-27 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Feb 25, 2015 at 09:47:26PM +0300, Ivan Shapovalov wrote:
> Suggested by Zbyszek on IRC.
> 
> This does not conditionalize on HAVE_PAM. Don't know whether that's right.
I added conditionalization on HAVE_PAM back, and will push this in a moment.

Zbyszek


> 
>  Makefile.am   | 37 
>  man/systemd-user-sessions.service.xml |  2 +-
>  src/login/Makefile|  1 -
>  src/login/user-sessions.c | 80 
> ---
>  src/user-sessions/Makefile|  1 +
>  src/user-sessions/user-sessions.c | 80 
> +++
>  6 files changed, 101 insertions(+), 100 deletions(-)
>  delete mode 12 src/login/Makefile
>  delete mode 100644 src/login/user-sessions.c
>  create mode 12 src/user-sessions/Makefile
>  create mode 100644 src/user-sessions/user-sessions.c
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] bootctl SIGSEGV

2015-02-27 Thread Oleksii Shevchuk
# bootctl
Segmentation fault (core dumped)
# gdb bootctl
GNU gdb (Gentoo 7.9 vanilla) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bootctl...Reading symbols from
/usr/lib64/debug//usr/bin/bootctl.debug...done.
done.
(gdb) r
Starting program: /usr/bin/bootctl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
bootctl_main.2553 (argc=, argv=) at
/tmp/portage/sys-apps/systemd-/work/systemd-/src/boot/bootctl.c:1333
1333efi_tilt_backslashes(loader_path);
(gdb) bt
#0  bootctl_main.2553 (argc=, argv=) at
/tmp/portage/sys-apps/systemd-/work/systemd-/src/boot/bootctl.c:1333
#1  0x7e25 in main (argc=, argv=)
at
/tmp/portage/sys-apps/systemd-/work/systemd-/src/boot/bootctl.c:1404
(gdb)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] pam_mount + mount.crypt regression

2015-02-27 Thread Oleksii Shevchuk
Hi,

Looks like this patch works for me.

// wbr
// Oleksii

2015-02-27 10:25 GMT+02:00 Martin Pitt :

> Hey Oleksii,
>
> Oleksii Shevchuk [2015-02-14 10:11 +0200]:
> > This patch 06e9783e2cc12eb6514e80c7f0014295f59b breaks pam_mount for
> me.
> > Without reverting it, systemd umounts encrypted drive, mounted with
> > dm-crypt/mount.crypt/pam_mount immediately.
> >
> > I double checked, that backing device is exported to systemd:
> > sys-devices-virtual-block-dm\x2d10.device loaded active plugged
> > /sys/devices/virtual/block/dm-10
>
> Can you please try the patch here:
>
>
> http://lists.freedesktop.org/archives/systemd-devel/2015-February/028812.html
>
> if it doesn't help, can you please describe how to reproduce this, and
> put a debug-enabled journal output from that boot, please?
>
> Thanks,
>
> Martin
> --
> Martin Pitt| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities

2015-02-27 Thread Jay Faulkner
Hi all,

My apologies if this is frowned upon, but this has been posted for a week and I 
haven’t gotten any feedback on it. I’d appreciate if this could get reviewed 
and if adequate, merged. I’m waiting on this change in order to be able to 
continue using systemd-nspawn containers, properly configured, to perform 
system tasks (such as firmware and bios flashing).

Thanks,
Jay Faulkner

On Feb 20, 2015, at 6:59 PM, Jay Faulkner mailto:j...@jvf.cc>> 
wrote:

After some additional testing, I found a bug in this patch where it would not 
compile with seccomp disabled. I’ve updated the patch at 
https://github.com/jayofdoom/systemd/pull/4.patch — also I’ve attached the 
fixed patch.

-Jay


On Feb 20, 2015, at 4:18 PM, Jay Faulkner mailto:j...@jvf.cc>> 
wrote:

Hi all,

At the suggestion (and with the assistance of) a co-worker, we remade this 
patch to not have quite as much repeated code. The new version is attached and 
can be found here https://github.com/jayofdoom/systemd/pull/4.patch — thanks!

Thanks,
Jay Faulkner
On Feb 20, 2015, at 2:24 PM, Jay Faulkner mailto:j...@jvf.cc>> 
wrote:

Hi all,

Two weeks ago[1] I patched systemd-nspawn to respect CAP_SYS_MODULE with 
regards to setting seccomp filters. As I needed access to some of the other 
blocked syscalls as well, I have a patch to map all seccomp filters to various 
capabilities, and to only set those filters if the matching capability is 
dropped. The matching capabilities were taken from the man pages of the 
syscalls involved.

I’d also suggest that in the future, additional filters use this same mapping 
as to avoid breaking use cases like mine in the future. :)

The patch is attached, but in case it gets mangled in transport as the last one 
did, feel free to get it directly from github here:  
https://github.com/jayofdoom/systemd/pull/3.patch.

Thanks,
Jay Faulkner

___
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

___
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] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier

2015-02-27 Thread Rauta, Alin
Thank you. 
/Alin

-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no] 
Sent: Friday, February 27, 2015 7:05 PM
To: Rauta, Alin
Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray
Subject: Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure 
Detection using BindCarrier

Hi Alin,

On Fri, Feb 27, 2015 at 6:44 AM, Rauta, Alin  wrote:
> Can we please draw a conclusion in this case ?

Sorry for the long time it has taken to get this patchset reviewed.

I have just gone through it now, and it looks great. You are right that the 
LINK_STATE_DOWN can be done separately. Pushed.

Thanks for all your work on this. Much appreciated!

Cheers,

Tom

> -Original Message-
> From: systemd-devel 
> [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of 
> Rauta, Alin
> Sent: Friday, February 20, 2015 10:37 AM
> To: Tom Gundersen
> Cc: Kinsella, Ray; systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] [PATCH v4] Added support for Uplink 
> Failure Detection using BindCarrier
>
> Hi Tom,
> Thank you. Please let me know if you have any questions regarding the 
> implementation.
> We can have another patch for the DOWN logic. It's a little bit complicated 
> since we don't have UP either and since during UP operation we don't know the 
> previous port state so that we get back to it.
> Best Regards,
> Alin
>
> -Original Message-
> From: Tom Gundersen [mailto:t...@jklm.no]
> Sent: Friday, February 20, 2015 10:27 AM
> To: Rauta, Alin
> Cc: lenn...@poettering.net; zbys...@in.waw.pl; 
> systemd-devel@lists.freedesktop.org; Kinsella, Ray
> Subject: Re: [PATCH v4] Added support for Uplink Failure Detection 
> using BindCarrier
>
> On Fri, Feb 20, 2015 at 10:50 AM, Rauta, Alin  wrote:
>> Hi Tom, Lennart, Zbyszek,
>> Did you have any chance to look at this patch version ?
>
> I hope to review it this weekend. I might go ahead and implement the DOWN 
> logic independently if that is still an issue (saw your question, but didn't 
> yet look at how you dealt with it in the patch). We need that anyway for 
> manually UP/DOWN of networks.
>
>> -Original Message-
>> From: Rauta, Alin
>> Sent: Tuesday, February 17, 2015 12:07 PM
>> To: t...@jklm.no; lenn...@poettering.net; zbys...@in.waw.pl
>> Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray; Rauta, Alin
>> Subject: [PATCH v4] Added support for Uplink Failure Detection using 
>> BindCarrier
>>
>> ---
>>  man/systemd.network.xml  |  11 +
>>  src/libsystemd/sd-network/sd-network.c   |   8 +
>>  src/network/networkctl.c |  43 ++--
>>  src/network/networkd-link.c  | 394 
>> +--
>>  src/network/networkd-link.h  |   3 +
>>  src/network/networkd-network-gperf.gperf |   1 +
>>  src/network/networkd-network.c   |   1 +
>>  src/network/networkd.h   |   2 +-
>>  src/systemd/sd-network.h |   6 +
>>  9 files changed, 438 insertions(+), 31 deletions(-)
>>
>> diff --git a/man/systemd.network.xml b/man/systemd.network.xml index
>> 485876b..60252e5 100644
>> --- a/man/systemd.network.xml
>> +++ b/man/systemd.network.xml
>> @@ -280,6 +280,17 @@
>>
>>  
>>  
>> +  BindCarrier=
>> +  
>> +A port or a list of ports. When set, controls the
>> +behaviour of the current interface. When all ports in the list
>> +are in an operational down state, the current interface is 
>> brought
>> +down. When at least one port has carrier, the current interface
>> +is brought up.
>> +
>> +  
>> +
>> +
>>Address=
>>
>>  A static IPv4 or IPv6 address and its prefix 
>> length, diff --git a/src/libsystemd/sd-network/sd-network.c
>> b/src/libsystemd/sd-network/sd-network.c
>> index c4713fe..fb5152c 100644
>> --- a/src/libsystemd/sd-network/sd-network.c
>> +++ b/src/libsystemd/sd-network/sd-network.c
>> @@ -264,6 +264,14 @@ _public_ int sd_network_link_get_domains(int ifindex, 
>> char ***ret) {
>>  return network_get_link_strv("DOMAINS", ifindex, ret);  }
>>
>> +_public_ int sd_network_link_get_carrier_bound_to(int ifindex, char ***ret) 
>> {
>> +return network_get_link_strv("CARRIER_BOUND_TO", ifindex, 
>> +ret); }
>> +
>> +_public_ int sd_network_link_get_carrier_bound_by(int ifindex, char ***ret) 
>> {
>> +return network_get_link_strv("CARRIER_BOUND_BY", ifindex, 
>> +ret); }
>> +
>>  _public_ int sd_network_link_get_wildcard_domain(int ifindex) {
>>  int r;
>>  _cleanup_free_ char *p = NULL, *s = NULL; diff --git 
>> a/src/network/networkctl.c b/src/network/networkctl.c index
>> aa83f32..0637513 100644
>> --- a/src/network/networkctl.c
>> +++ b/src/network/networkctl.c
>> @@ -508,6 +508,8 @@ static int link_status_one(
>>  const char *driver = NULL, *path = NULL, *vendor = NULL, *model = 
>> NULL, *l

Re: [systemd-devel] nilfs-cleanerd startup on boot

2015-02-27 Thread Jóhann B. Guðmundsson

On 02/27/2015 06:31 PM, dennis.mur...@wipro.com wrote:

I have a fedora 21 system that where I mount an nilfs2 file system.  I use a 
simple /etc/modules-load.d/nilfs.conf file to load the kernel module and have 
an entry in the fstab.  The file system mounts on boot as it should, but the 
nilfs-cleanerd program does not startup.  If I umount /nilfs then mount /nilfs 
the nilfs-cleanerd program starts as it should to cleanup the checkpoints.


Hmm this should just work as long as it has been built with libmount 
support.


Check the spec file in Fedora ( it should contain --with-libmount and or 
-enable-libmount in %configure line )


If it has not been built with libmount support, download the source from 
koji, rebuild it with it enabled, test it and file a bug in Fedora if it 
works.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] boot: efi - move background pixel variable into different scope

2015-02-27 Thread Kay Sievers
On Fri, Feb 27, 2015 at 6:12 PM, Marcel Holtmann  wrote:
>>>  CC   src/boot/efi/splash.o
>>> src/boot/efi/splash.c: In function ‘graphics_splash’:
>>> src/boot/efi/splash.c:256:9: warning: missing initializer for field ‘Blue’ 
>>> of ‘EFI_GRAPHICS_OUTPUT_BLT_PIXEL’ [-Wmissing-field-initializers]
>>> EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { };
>>> ^
>>> In file included from /usr/include/efi/efi.h:39:0,
>>> from src/boot/efi/splash.c:18:
>>> /usr/include/efi/efiprot.h:641:9: note: ‘Blue’ declared here
>>>   UINT8 Blue;
>>> ^
>>
>> That patch removes the initializer?
>
> indeed, if you do not have background provided, then it is undefined. And 
> also in the Apple case, the Reserved field would not be set. Anyway, I have 
> no idea on how to fix this compiler warning the right way.
>
> Alternatively doing something like this shuts it up as well:
>
>  EFI_STATUS graphics_splash(UINT8 *content, UINTN len, const 
> EFI_GRAPHICS_OUTPUT_BLT_PIXEL *background) {
> -EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = {};
> +EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { 0x00, };

I guess we should just add -Wno-missing-field-initializers, like we do
for the systemd code?

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier

2015-02-27 Thread Tom Gundersen
Hi Alin,

On Fri, Feb 27, 2015 at 6:44 AM, Rauta, Alin  wrote:
> Can we please draw a conclusion in this case ?

Sorry for the long time it has taken to get this patchset reviewed.

I have just gone through it now, and it looks great. You are right
that the LINK_STATE_DOWN can be done separately. Pushed.

Thanks for all your work on this. Much appreciated!

Cheers,

Tom

> -Original Message-
> From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
> Behalf Of Rauta, Alin
> Sent: Friday, February 20, 2015 10:37 AM
> To: Tom Gundersen
> Cc: Kinsella, Ray; systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure 
> Detection using BindCarrier
>
> Hi Tom,
> Thank you. Please let me know if you have any questions regarding the 
> implementation.
> We can have another patch for the DOWN logic. It's a little bit complicated 
> since we don't have UP either and since during UP operation we don't know the 
> previous port state so that we get back to it.
> Best Regards,
> Alin
>
> -Original Message-
> From: Tom Gundersen [mailto:t...@jklm.no]
> Sent: Friday, February 20, 2015 10:27 AM
> To: Rauta, Alin
> Cc: lenn...@poettering.net; zbys...@in.waw.pl; 
> systemd-devel@lists.freedesktop.org; Kinsella, Ray
> Subject: Re: [PATCH v4] Added support for Uplink Failure Detection using 
> BindCarrier
>
> On Fri, Feb 20, 2015 at 10:50 AM, Rauta, Alin  wrote:
>> Hi Tom, Lennart, Zbyszek,
>> Did you have any chance to look at this patch version ?
>
> I hope to review it this weekend. I might go ahead and implement the DOWN 
> logic independently if that is still an issue (saw your question, but didn't 
> yet look at how you dealt with it in the patch). We need that anyway for 
> manually UP/DOWN of networks.
>
>> -Original Message-
>> From: Rauta, Alin
>> Sent: Tuesday, February 17, 2015 12:07 PM
>> To: t...@jklm.no; lenn...@poettering.net; zbys...@in.waw.pl
>> Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray; Rauta, Alin
>> Subject: [PATCH v4] Added support for Uplink Failure Detection using
>> BindCarrier
>>
>> ---
>>  man/systemd.network.xml  |  11 +
>>  src/libsystemd/sd-network/sd-network.c   |   8 +
>>  src/network/networkctl.c |  43 ++--
>>  src/network/networkd-link.c  | 394 
>> +--
>>  src/network/networkd-link.h  |   3 +
>>  src/network/networkd-network-gperf.gperf |   1 +
>>  src/network/networkd-network.c   |   1 +
>>  src/network/networkd.h   |   2 +-
>>  src/systemd/sd-network.h |   6 +
>>  9 files changed, 438 insertions(+), 31 deletions(-)
>>
>> diff --git a/man/systemd.network.xml b/man/systemd.network.xml index
>> 485876b..60252e5 100644
>> --- a/man/systemd.network.xml
>> +++ b/man/systemd.network.xml
>> @@ -280,6 +280,17 @@
>>
>>  
>>  
>> +  BindCarrier=
>> +  
>> +A port or a list of ports. When set, controls the
>> +behaviour of the current interface. When all ports in the list
>> +are in an operational down state, the current interface is 
>> brought
>> +down. When at least one port has carrier, the current interface
>> +is brought up.
>> +
>> +  
>> +
>> +
>>Address=
>>
>>  A static IPv4 or IPv6 address and its prefix
>> length, diff --git a/src/libsystemd/sd-network/sd-network.c
>> b/src/libsystemd/sd-network/sd-network.c
>> index c4713fe..fb5152c 100644
>> --- a/src/libsystemd/sd-network/sd-network.c
>> +++ b/src/libsystemd/sd-network/sd-network.c
>> @@ -264,6 +264,14 @@ _public_ int sd_network_link_get_domains(int ifindex, 
>> char ***ret) {
>>  return network_get_link_strv("DOMAINS", ifindex, ret);  }
>>
>> +_public_ int sd_network_link_get_carrier_bound_to(int ifindex, char ***ret) 
>> {
>> +return network_get_link_strv("CARRIER_BOUND_TO", ifindex,
>> +ret); }
>> +
>> +_public_ int sd_network_link_get_carrier_bound_by(int ifindex, char ***ret) 
>> {
>> +return network_get_link_strv("CARRIER_BOUND_BY", ifindex,
>> +ret); }
>> +
>>  _public_ int sd_network_link_get_wildcard_domain(int ifindex) {
>>  int r;
>>  _cleanup_free_ char *p = NULL, *s = NULL; diff --git
>> a/src/network/networkctl.c b/src/network/networkctl.c index
>> aa83f32..0637513 100644
>> --- a/src/network/networkctl.c
>> +++ b/src/network/networkctl.c
>> @@ -508,6 +508,8 @@ static int link_status_one(
>>  const char *driver = NULL, *path = NULL, *vendor = NULL, *model = 
>> NULL, *link = NULL;
>>  const char *on_color_operational, *off_color_operational,
>> *on_color_setup, *off_color_setup;
>> +_cleanup_strv_free_ char **carrier_bound_to = NULL;
>> +_cleanup_strv_free_ char **carrier_bound_by = NULL;
>>  struct ether_addr e;
>> 

[systemd-devel] nilfs-cleanerd startup on boot

2015-02-27 Thread dennis.murata
I have a fedora 21 system that where I mount an nilfs2 file system.  I use a 
simple /etc/modules-load.d/nilfs.conf file to load the kernel module and have 
an entry in the fstab.  The file system mounts on boot as it should, but the 
nilfs-cleanerd program does not startup.  If I umount /nilfs then mount /nilfs 
the nilfs-cleanerd program starts as it should to cleanup the checkpoints.

Does systemd use a different mount program at boot?  Is there something else 
that should be included other than the nilfs.conf file?  I have just started 
using a system with systemd as the init so please forgive my ignorance.

Wayne
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [v1] shutdown: add kexec loading, ?avoid calling `kexec` binary unnessecarily

2015-02-27 Thread Shawn Landden
On Fri, Feb 27, 2015 at 9:03 AM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> > We need two operations: sorting kernels to list them, and picking (I

> On Fri, Feb 27, 2015 at 08:58:04AM -0800, Shawn Landden wrote:
> > On Thu, Feb 26, 2015 at 6:22 PM, Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:
> >
> > > On Thu, Feb 26, 2015 at 08:04:08AM +, Jan Janssen wrote:
> > > > Shawn Landden  churchofgit.com> writes:
> > > >
> > > > >  void strv_free(char **l) {
> > > > > -strv_clear(l);
> > > > > +char **k;
> > > > > +
> > > > > +if (!l)
> > > > > +return;
> > > > > +
> > > > > +for (k = l; *k; k++)
> > > > > +free(*k);
> > > > > +
> > > > >  free(l);
> > > > >  }
> > > > What are you trying to achieve here? I see no point in optimizing out
> > > the *l
> > > > = NULL from strv_clear.
> > > >
> > > > > +entry->linux_loc  = l + strspn(l,
> > > > WHITESPACE);
> > > > > +else if ((l = startswith(m, "initrd ")))
> > > > > +entry->initrd = l + strspn(l,
> > > > WHITESPACE);
> > > > You need to support more than one initrd per kernel, see
> > > > https://wiki.archlinux.org/index.php/Microcode for why. Also, I am
> > > pretty
> > > > sure you can have a initrd=/path/to/initrd in the kernel options
> entry.
> > > > Since the efi bootloader just appends each given initrd to the kernel
> > > > command line.
> > > >
> > > >
> > > > All in all I am wondering why you need a rbtree for all this in the
> first
> > > > place? A simple hashmap should do just fine.
> > > A hashmap does not keep order. But a simple array + qsort_safe() should
> > > work too. I'm wary of introducing yet another data structure into
> systemd
> > > which raises the bar for people editing the code later on or making
> > > changes.
> > >
> > > presume) the
> > > latest kernel or the kernel with the given version. Both of those
> > > operations
> > > are done once over the lifetime of the program, so any speedup in using
> > > a data structure should take into account the time to set up the
> structure.
> > > Neither of those operations is speed sensitive, and the more common
> > > operation
> > > of picking a specific version can be done in O(n) over an array. So
> using
> > > an rbtree will not save any time actually.
> > >
> > I was initially using a vector of pointers here for the same reasons you
> > reiterated, but I felt the use of greedy_realloc0() was messy and
> > error-prone.
> greedy_realloc0() is not that messy. And it would be just a few lines
> of code. We have similar patterns in many other places, and
> consistency is good.
>
> > The rbtree does not require the use of realloc(). There is no
> > way to know how long the array needs to be from the start. Even the O(n)
> > you mention could be turned into O(logn) by using a binary search.
> Nope. The array needs to be sorted to do a binary search. So the
> upfront cost of sorting kills any gain you get later on.
>
Oh I see, you don't have to sort in that case. But the code would be
longer, so perhaps I will sort in all cases.

>
> Zbyszek
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Shawn Landden
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] boot: efi - move background pixel variable into different scope

2015-02-27 Thread Marcel Holtmann
Hi Kay,

>>  CC   src/boot/efi/splash.o
>> src/boot/efi/splash.c: In function ‘graphics_splash’:
>> src/boot/efi/splash.c:256:9: warning: missing initializer for field ‘Blue’ 
>> of ‘EFI_GRAPHICS_OUTPUT_BLT_PIXEL’ [-Wmissing-field-initializers]
>> EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { };
>> ^
>> In file included from /usr/include/efi/efi.h:39:0,
>> from src/boot/efi/splash.c:18:
>> /usr/include/efi/efiprot.h:641:9: note: ‘Blue’ declared here
>>   UINT8 Blue;
>> ^
> 
> That patch removes the initializer?

indeed, if you do not have background provided, then it is undefined. And also 
in the Apple case, the Reserved field would not be set. Anyway, I have no idea 
on how to fix this compiler warning the right way.

Alternatively doing something like this shuts it up as well:

 EFI_STATUS graphics_splash(UINT8 *content, UINTN len, const 
EFI_GRAPHICS_OUTPUT_BLT_PIXEL *background) {
-EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = {};
+EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { 0x00, };

Regards

Marcel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [v1] shutdown: add kexec loading, ?avoid calling `kexec` binary unnessecarily

2015-02-27 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Feb 27, 2015 at 08:58:04AM -0800, Shawn Landden wrote:
> On Thu, Feb 26, 2015 at 6:22 PM, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > On Thu, Feb 26, 2015 at 08:04:08AM +, Jan Janssen wrote:
> > > Shawn Landden  churchofgit.com> writes:
> > >
> > > >  void strv_free(char **l) {
> > > > -strv_clear(l);
> > > > +char **k;
> > > > +
> > > > +if (!l)
> > > > +return;
> > > > +
> > > > +for (k = l; *k; k++)
> > > > +free(*k);
> > > > +
> > > >  free(l);
> > > >  }
> > > What are you trying to achieve here? I see no point in optimizing out
> > the *l
> > > = NULL from strv_clear.
> > >
> > > > +entry->linux_loc  = l + strspn(l,
> > > WHITESPACE);
> > > > +else if ((l = startswith(m, "initrd ")))
> > > > +entry->initrd = l + strspn(l,
> > > WHITESPACE);
> > > You need to support more than one initrd per kernel, see
> > > https://wiki.archlinux.org/index.php/Microcode for why. Also, I am
> > pretty
> > > sure you can have a initrd=/path/to/initrd in the kernel options entry.
> > > Since the efi bootloader just appends each given initrd to the kernel
> > > command line.
> > >
> > >
> > > All in all I am wondering why you need a rbtree for all this in the first
> > > place? A simple hashmap should do just fine.
> > A hashmap does not keep order. But a simple array + qsort_safe() should
> > work too. I'm wary of introducing yet another data structure into systemd
> > which raises the bar for people editing the code later on or making
> > changes.
> >
> > We need two operations: sorting kernels to list them, and picking (I
> > presume) the
> > latest kernel or the kernel with the given version. Both of those
> > operations
> > are done once over the lifetime of the program, so any speedup in using
> > a data structure should take into account the time to set up the structure.
> > Neither of those operations is speed sensitive, and the more common
> > operation
> > of picking a specific version can be done in O(n) over an array. So using
> > an rbtree will not save any time actually.
> >
> I was initially using a vector of pointers here for the same reasons you
> reiterated, but I felt the use of greedy_realloc0() was messy and
> error-prone.
greedy_realloc0() is not that messy. And it would be just a few lines
of code. We have similar patterns in many other places, and
consistency is good.

> The rbtree does not require the use of realloc(). There is no
> way to know how long the array needs to be from the start. Even the O(n)
> you mention could be turned into O(logn) by using a binary search.
Nope. The array needs to be sorted to do a binary search. So the
upfront cost of sorting kills any gain you get later on.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [v1] shutdown: add kexec loading, ?avoid calling `kexec` binary unnessecarily

2015-02-27 Thread Shawn Landden
On Thu, Feb 26, 2015 at 6:22 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Thu, Feb 26, 2015 at 08:04:08AM +, Jan Janssen wrote:
> > Shawn Landden  churchofgit.com> writes:
> >
> > >  void strv_free(char **l) {
> > > -strv_clear(l);
> > > +char **k;
> > > +
> > > +if (!l)
> > > +return;
> > > +
> > > +for (k = l; *k; k++)
> > > +free(*k);
> > > +
> > >  free(l);
> > >  }
> > What are you trying to achieve here? I see no point in optimizing out
> the *l
> > = NULL from strv_clear.
> >
> > > +entry->linux_loc  = l + strspn(l,
> > WHITESPACE);
> > > +else if ((l = startswith(m, "initrd ")))
> > > +entry->initrd = l + strspn(l,
> > WHITESPACE);
> > You need to support more than one initrd per kernel, see
> > https://wiki.archlinux.org/index.php/Microcode for why. Also, I am
> pretty
> > sure you can have a initrd=/path/to/initrd in the kernel options entry.
> > Since the efi bootloader just appends each given initrd to the kernel
> > command line.
> >
> >
> > All in all I am wondering why you need a rbtree for all this in the first
> > place? A simple hashmap should do just fine.
> A hashmap does not keep order. But a simple array + qsort_safe() should
> work too. I'm wary of introducing yet another data structure into systemd
> which raises the bar for people editing the code later on or making
> changes.
>
> We need two operations: sorting kernels to list them, and picking (I
> presume) the
> latest kernel or the kernel with the given version. Both of those
> operations
> are done once over the lifetime of the program, so any speedup in using
> a data structure should take into account the time to set up the structure.
> Neither of those operations is speed sensitive, and the more common
> operation
> of picking a specific version can be done in O(n) over an array. So using
> an rbtree will not save any time actually.
>
I was initially using a vector of pointers here for the same reasons you
reiterated, but I felt the use of greedy_realloc0() was messy and
error-prone. The rbtree does not require the use of realloc(). There is no
way to know how long the array needs to be from the start. Even the O(n)
you mention could be turned into O(logn) by using a binary search.

>
> > Also, you're not taking multi-boot into account (the machine-id field).
> > You're just discriminating based on the kernel version, but different
> > installations could have the same version field.
> This high-level design questions should probably be addressed first...
>
> Zbyszek
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Shawn Landden
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 3/8] power: refactor the three power management binaries to src/power

2015-02-27 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Feb 27, 2015 at 08:52:34AM -0800, Shawn Landden wrote:
> On Thu, Feb 26, 2015 at 6:26 PM, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > I'm not sure we want this... Can you add some justification? Do they share
> > code?
> >
> I found it confusing what parts each of these handled, and some code
> sharing is possible, but none is shared currently. This also eliminates one
> directory. All of these are handled by units:
> 
> sleep.target
> shutdown.target
> etc...
> 
> >
> > On Fri, Feb 20, 2015 at 02:31:00PM -0800, Shawn Landden wrote:
> > > ---
> > >  Makefile.am   |   6 +-
> > >  src/core/shutdown.c   | 420
> > -
> > >  src/power/Makefile|  28 +++
> > This should be a symlink.
> >
> > To make all of these symlinks would be a much larger patch, but I can send
> such a patch
You removed src/shutdownd/Makefile which was a symlink, and added
src/power/Makefile which is a real file.

Zbyszek

> 
> > >  src/power/shutdown.c  | 420
> > +
> > >  src/power/shutdownd.c | 461
> > ++
> > >  src/power/sleep.c | 219 ++
> > >  src/shutdownd/Makefile|   1 -
> > >  src/shutdownd/shutdownd.c | 461
> > --
> > >  src/sleep/Makefile|   1 -
> > >  src/sleep/sleep.c | 219 --
> > >  10 files changed, 1131 insertions(+), 1105 deletions(-)
> > >  delete mode 100644 src/core/shutdown.c
> > >  create mode 100644 src/power/Makefile
> > >  create mode 100644 src/power/shutdown.c
> > >  create mode 100644 src/power/shutdownd.c
> > >  create mode 100644 src/power/sleep.c
> > >  delete mode 12 src/shutdownd/Makefile
> > >  delete mode 100644 src/shutdownd/shutdownd.c
> > >  delete mode 12 src/sleep/Makefile
> > >  delete mode 100644 src/sleep/sleep.c
> > It's better to use -M for such patches... Make it easier to see what is
> > hapenning.
> >
> > Zbyszek
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
> 
> 
> 
> -- 
> Shawn Landden
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 3/8] power: refactor the three power management binaries to src/power

2015-02-27 Thread Shawn Landden
On Thu, Feb 26, 2015 at 6:26 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> I'm not sure we want this... Can you add some justification? Do they share
> code?
>
I found it confusing what parts each of these handled, and some code
sharing is possible, but none is shared currently. This also eliminates one
directory. All of these are handled by units:

sleep.target
shutdown.target
etc...

>
> On Fri, Feb 20, 2015 at 02:31:00PM -0800, Shawn Landden wrote:
> > ---
> >  Makefile.am   |   6 +-
> >  src/core/shutdown.c   | 420
> -
> >  src/power/Makefile|  28 +++
> This should be a symlink.
>
> To make all of these symlinks would be a much larger patch, but I can send
such a patch

> >  src/power/shutdown.c  | 420
> +
> >  src/power/shutdownd.c | 461
> ++
> >  src/power/sleep.c | 219 ++
> >  src/shutdownd/Makefile|   1 -
> >  src/shutdownd/shutdownd.c | 461
> --
> >  src/sleep/Makefile|   1 -
> >  src/sleep/sleep.c | 219 --
> >  10 files changed, 1131 insertions(+), 1105 deletions(-)
> >  delete mode 100644 src/core/shutdown.c
> >  create mode 100644 src/power/Makefile
> >  create mode 100644 src/power/shutdown.c
> >  create mode 100644 src/power/shutdownd.c
> >  create mode 100644 src/power/sleep.c
> >  delete mode 12 src/shutdownd/Makefile
> >  delete mode 100644 src/shutdownd/shutdownd.c
> >  delete mode 12 src/sleep/Makefile
> >  delete mode 100644 src/sleep/sleep.c
> It's better to use -M for such patches... Make it easier to see what is
> hapenning.
>
> Zbyszek
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Shawn Landden
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] unit: When stopping due to BindsTo=, log which unit caused it

2015-02-27 Thread Lennart Poettering
On Thu, 26.02.15 16:50, Martin Pitt (martin.p...@ubuntu.com) wrote:

> IMHO it would be prudent to skip adding the BindsTo= if at the time of
> creating the .mount unit the backing .device unit doesn't actually
> exist. In that case it's a mount which isn't managed by systemd, and
> we shouldn't touch it. We mostly want this BindsTo= for mounts where
> the .device units *do* exist, so that when they go away we can clean
> up the mount (mostly for hotpluggable devices and removable media).
> I'll have a deeper look ASAP.

I ran into this myself the other day, and Kay, Daniel and I spent a
lot of time to come up with a scheme how to deal with the race... And
I think we have a nice scheme now and I started implementing it.

The idea is that .device units will gain a third state: currently they
are either "dead" or "plugged", and the new state will be
"tentative". It is entered when a device is referenced in
/proc/self/mountinfo or /proc/swap, even though it has not yet shown
up via udev.

This new state has will not result in BindsTo= getting active.

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 2/2] vconsole: set font on tty16..tty63 as well

2015-02-27 Thread David Herrmann
Hi

On Fri, Feb 27, 2015 at 4:09 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Feb 26, 2015 at 01:37:25PM +0100, Jan Engelhardt wrote:
>>
>> On Wednesday 2015-02-25 21:10, Lennart Poettering wrote:
>> >> >> The setup program would not set the font on tty16 upwards.
>> >> >> There is a maximum of 63 VCs possible in Linux. (That number is
>> >> >> hardcoded.)
>> >> >
>> >> >We deliberately do not support such high VTs in systemds.
>> >>
>> >> And what's the rationale?
>> >
>> >Initially it was that we had the "systemd" udev tag on all VCs, which
>> >made them appear as .device units in systemd, and I really didn't want
>> >63 of them. Then, some of the VC ioctls have a 16bit bitmap, which
>> >makes the higher VCs not as accesible.
>> >What's your usecase for this?
>>
>> No particular usecase. I just stumbled across this arbitrary number
>> 15/16 in the source code while I was figuring out the font reload
>> mess. The patches sent,
>>   vconsole: rerun setup on console takeovers as well
>>   vconsole: match on vtcon events, not fbcon ones,
>> are still very much desired to have included.
> One reason I see is automated tools which want to open many consoles
> (for debug output or whatever), without stepping on the toes of the
> user. They might start with tty20 or something.
>
> If the trick with checking for /dev/vcsXX works, I don't see why
> we shouldn't support the full set provided by the kernel. One magic
> number less is always good.

It does not work. vcs are available if the VT is allocated, but
v_state returns information whether someone actually has the VT
_opened_.

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] boot: efi - move background pixel variable into different scope

2015-02-27 Thread Kay Sievers
On Fri, Feb 27, 2015 at 1:35 AM, Marcel Holtmann  wrote:
>   CC   src/boot/efi/splash.o
> src/boot/efi/splash.c: In function ‘graphics_splash’:
> src/boot/efi/splash.c:256:9: warning: missing initializer for field ‘Blue’ of 
> ‘EFI_GRAPHICS_OUTPUT_BLT_PIXEL’ [-Wmissing-field-initializers]
>  EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { };
>  ^
> In file included from /usr/include/efi/efi.h:39:0,
>  from src/boot/efi/splash.c:18:
> /usr/include/efi/efiprot.h:641:9: note: ‘Blue’ declared here
>UINT8 Blue;
>  ^

That patch removes the initializer?

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier

2015-02-27 Thread Rauta, Alin
Can we please draw a conclusion in this case ?
Regards,
Alin 

-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of Rauta, Alin
Sent: Friday, February 20, 2015 10:37 AM
To: Tom Gundersen
Cc: Kinsella, Ray; systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure 
Detection using BindCarrier

Hi Tom,
Thank you. Please let me know if you have any questions regarding the 
implementation.
We can have another patch for the DOWN logic. It's a little bit complicated 
since we don't have UP either and since during UP operation we don't know the 
previous port state so that we get back to it.
Best Regards,
Alin

-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Friday, February 20, 2015 10:27 AM
To: Rauta, Alin
Cc: lenn...@poettering.net; zbys...@in.waw.pl; 
systemd-devel@lists.freedesktop.org; Kinsella, Ray
Subject: Re: [PATCH v4] Added support for Uplink Failure Detection using 
BindCarrier

On Fri, Feb 20, 2015 at 10:50 AM, Rauta, Alin  wrote:
> Hi Tom, Lennart, Zbyszek,
> Did you have any chance to look at this patch version ?

I hope to review it this weekend. I might go ahead and implement the DOWN logic 
independently if that is still an issue (saw your question, but didn't yet look 
at how you dealt with it in the patch). We need that anyway for manually 
UP/DOWN of networks.

> -Original Message-
> From: Rauta, Alin
> Sent: Tuesday, February 17, 2015 12:07 PM
> To: t...@jklm.no; lenn...@poettering.net; zbys...@in.waw.pl
> Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray; Rauta, Alin
> Subject: [PATCH v4] Added support for Uplink Failure Detection using 
> BindCarrier
>
> ---
>  man/systemd.network.xml  |  11 +
>  src/libsystemd/sd-network/sd-network.c   |   8 +
>  src/network/networkctl.c |  43 ++--
>  src/network/networkd-link.c  | 394 
> +--
>  src/network/networkd-link.h  |   3 +
>  src/network/networkd-network-gperf.gperf |   1 +
>  src/network/networkd-network.c   |   1 +
>  src/network/networkd.h   |   2 +-
>  src/systemd/sd-network.h |   6 +
>  9 files changed, 438 insertions(+), 31 deletions(-)
>
> diff --git a/man/systemd.network.xml b/man/systemd.network.xml index
> 485876b..60252e5 100644
> --- a/man/systemd.network.xml
> +++ b/man/systemd.network.xml
> @@ -280,6 +280,17 @@
>
>  
>  
> +  BindCarrier=
> +  
> +A port or a list of ports. When set, controls the
> +behaviour of the current interface. When all ports in the list
> +are in an operational down state, the current interface is 
> brought
> +down. When at least one port has carrier, the current interface
> +is brought up.
> +
> +  
> +
> +
>Address=
>
>  A static IPv4 or IPv6 address and its prefix 
> length, diff --git a/src/libsystemd/sd-network/sd-network.c
> b/src/libsystemd/sd-network/sd-network.c
> index c4713fe..fb5152c 100644
> --- a/src/libsystemd/sd-network/sd-network.c
> +++ b/src/libsystemd/sd-network/sd-network.c
> @@ -264,6 +264,14 @@ _public_ int sd_network_link_get_domains(int ifindex, 
> char ***ret) {
>  return network_get_link_strv("DOMAINS", ifindex, ret);  }
>
> +_public_ int sd_network_link_get_carrier_bound_to(int ifindex, char ***ret) {
> +return network_get_link_strv("CARRIER_BOUND_TO", ifindex, 
> +ret); }
> +
> +_public_ int sd_network_link_get_carrier_bound_by(int ifindex, char ***ret) {
> +return network_get_link_strv("CARRIER_BOUND_BY", ifindex, 
> +ret); }
> +
>  _public_ int sd_network_link_get_wildcard_domain(int ifindex) {
>  int r;
>  _cleanup_free_ char *p = NULL, *s = NULL; diff --git 
> a/src/network/networkctl.c b/src/network/networkctl.c index
> aa83f32..0637513 100644
> --- a/src/network/networkctl.c
> +++ b/src/network/networkctl.c
> @@ -508,6 +508,8 @@ static int link_status_one(
>  const char *driver = NULL, *path = NULL, *vendor = NULL, *model = 
> NULL, *link = NULL;
>  const char *on_color_operational, *off_color_operational,
> *on_color_setup, *off_color_setup;
> +_cleanup_strv_free_ char **carrier_bound_to = NULL;
> +_cleanup_strv_free_ char **carrier_bound_by = NULL;
>  struct ether_addr e;
>  unsigned iftype;
>  int r, ifindex;
> @@ -606,12 +608,15 @@ static int link_status_one(
>
>  sd_network_link_get_network_file(ifindex, &network);
>
> +sd_network_link_get_carrier_bound_to(ifindex, &carrier_bound_to);
> +sd_network_link_get_carrier_bound_by(ifindex,
> + &carrier_bound_by);
> +
>  printf("%s%s%s %i: %s\n", on_color_operational, 
> draw_special_char(DRAW_BLACK_CIRCLE), off_color_operational, ifinde

Re: [systemd-devel] [PATCH 1/2] vconsole: match on vtcon events, not fbcon ones

2015-02-27 Thread Jan Engelhardt

On Friday 2015-02-27 04:12, Zbigniew Jędrzejewski-Szmek wrote:
>On Tue, Feb 24, 2015 at 05:49:02PM +0100, Jan Engelhardt wrote:
>
>> +ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", 
>> RUN+="@rootlibexecdir@/systemd-vconsole-setup"
>> 
>> The fbcon driver may be loaded at a time way before the first
>> framebuffer device is active, such that the vconsole setup helper
>> runs too early.
>
>OK, but what happens when fbcon is loaded afterwards?

The vtcon ADD event occurs after both modules (fbcon and a fitting hw
driver) have initialized, irrespective of the loading order of the
two.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] hwdb: add sdio identifiers for Broadcom WLAN cards

2015-02-27 Thread Arend van Spriel

On 02/27/15 01:24, Marcel Holtmann wrote:

Hi Arend,


This patch adds the sdio identifiers known to be supported by
the brcmfmac open-source driver.

Cc: Marcel Holtmann
Signed-off-by: Arend van Spriel


I remove the signed-off-by line since it is not standard practice here and then 
applied the patch.


Ok. Fine by me. I noticed you already mentioned that when I did first 
attempt, but that one never got through because I was not subscribed to 
the systemd-devel list.


Thanks for applying it.

Regards,
Arend
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] pam_mount + mount.crypt regression

2015-02-27 Thread Martin Pitt
Hey Oleksii,

Oleksii Shevchuk [2015-02-14 10:11 +0200]:
> This patch 06e9783e2cc12eb6514e80c7f0014295f59b breaks pam_mount for me.
> Without reverting it, systemd umounts encrypted drive, mounted with
> dm-crypt/mount.crypt/pam_mount immediately.
> 
> I double checked, that backing device is exported to systemd:
> sys-devices-virtual-block-dm\x2d10.device loaded active plugged
> /sys/devices/virtual/block/dm-10

Can you please try the patch here:

  http://lists.freedesktop.org/archives/systemd-devel/2015-February/028812.html

if it doesn't help, can you please describe how to reproduce this, and
put a debug-enabled journal output from that boot, please?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel