Re: [systemd-devel] [PATCH] manager: Ensure user's systemd runtime directory exists.
Zbigniew Jędrzejewski-Szmek wrote on 02/11/14 18:18: On Sun, Nov 02, 2014 at 02:04:20PM +, Colin Guthrie wrote: This mirrors code in dbus.c when creating the private socket and avoids error messages like: systemd[1353]: bind(/run/user/603/systemd/notify) failed: No such file or directory systemd[1353]: Failed to fully start up daemon: No such file or directory Seems reasonable. But why not move the mkdir_parent_label() to the shared code path? Even if the dir is created elsewhere, it seems cleaner to ensure here that it is available. Well, to be honest, I just copied the structure from dbus.c. I can easily do as you suggest in both places if you think it's nicer. I guess this would add two unnecessary stat()s (at least - not looked at the mkdir... implementation!) on boot however, so might just be better leaving it as is (not that that is a real problem practically speaking, especially in tmpfs!). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statelessy system
It was 2014-10-31 pią 17:04, when Zbigniew Jędrzejewski-Szmek wrote: On Fri, Oct 31, 2014 at 02:06:37PM +0100, Łukasz Stelmach wrote: My question: is v217 ready to run without /etc/systemd/*.conf and read them from /usr/lib/systemd wher I (vendor) can put properly tailored files? Hi Łukasz, if you look into those files, you'll see that they contain only comments. Indeed, however, that only means systemd's got sane defaults. What if I want to provide some distro-wide configuration that is different from yours? -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgpBQHbGnJXLf.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statelessy system
It was 2014-11-02 nie 19:06, when Lennart Poettering wrote: On Fri, 31.10.14 14:06, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Hello. I am working to upgrade systemd in Tizen to v217 from v212. To verify rpm packages we use rpmlint with some rules from opensuse[1]. For whatever reason v217 package exceed allowed badness because it puts config files (system.conf, journald.conf etc) in /etc/systemd. The check [2] forbids putting anything in there and it seems to go along weel with the sateless system goal of systemd. My question: is v217 ready to run without /etc/systemd/*.conf and read them from /usr/lib/systemd wher I (vendor) can put properly tailored files? Yes, /etc/systemd is unnecessary for booting. If you find any of our tools not working if /etc/systemd is removed it would be a bug. As I wrote in a message to Zbyszek, what if I want my distro defaults to be different than those (no matter they are sane) of yours? -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgpcDOpureK9x.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statelessy system
On Mon, 03.11.14 09:48, Łukasz Stelmach (l.stelm...@samsung.com) wrote: It was 2014-11-02 nie 19:06, when Lennart Poettering wrote: On Fri, 31.10.14 14:06, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Hello. I am working to upgrade systemd in Tizen to v217 from v212. To verify rpm packages we use rpmlint with some rules from opensuse[1]. For whatever reason v217 package exceed allowed badness because it puts config files (system.conf, journald.conf etc) in /etc/systemd. The check [2] forbids putting anything in there and it seems to go along weel with the sateless system goal of systemd. My question: is v217 ready to run without /etc/systemd/*.conf and read them from /usr/lib/systemd wher I (vendor) can put properly tailored files? Yes, /etc/systemd is unnecessary for booting. If you find any of our tools not working if /etc/systemd is removed it would be a bug. As I wrote in a message to Zbyszek, what if I want my distro defaults to be different than those (no matter they are sane) of yours? Well, if it's units and stuff they should live in /usr. If you want to configured things like system.conf or logind.conf or so, then I figure you currently would have to patch the systemd source code. Would be happy to take a patch that makes those cases check for a config file in /usr/lib as fallback though, to cover all bases. 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] sd-pppoe: include ppp_defs.h
On older kernels before this patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e8b671460410c8fd996c8a1c228b718c547cc236 ppp-ioctl.h did not pull in ppp_defs.h which results in build errors --- src/libsystemd-network/sd-pppoe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/libsystemd-network/sd-pppoe.c b/src/libsystemd-network/sd-pppoe.c index 6f33541..21ddaeb 100644 --- a/src/libsystemd-network/sd-pppoe.c +++ b/src/libsystemd-network/sd-pppoe.c @@ -22,6 +22,7 @@ /* See RFC 2516 */ #include sys/ioctl.h +#include linux/ppp_defs.h #include linux/ppp-ioctl.h #include net/if.h #include netinet/in.h -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-pppoe: include ppp_defs.h
Applied. Thanks! Tom On Mon, Nov 3, 2014 at 12:31 PM, Lukas Nykryn lnyk...@redhat.com wrote: On older kernels before this patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e8b671460410c8fd996c8a1c228b718c547cc236 ppp-ioctl.h did not pull in ppp_defs.h which results in build errors --- src/libsystemd-network/sd-pppoe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/libsystemd-network/sd-pppoe.c b/src/libsystemd-network/sd-pppoe.c index 6f33541..21ddaeb 100644 --- a/src/libsystemd-network/sd-pppoe.c +++ b/src/libsystemd-network/sd-pppoe.c @@ -22,6 +22,7 @@ /* See RFC 2516 */ #include sys/ioctl.h +#include linux/ppp_defs.h #include linux/ppp-ioctl.h #include net/if.h #include netinet/in.h -- 1.8.3.1 ___ 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 2/5] libsystemd:terminal :fix uninitialized warning
Hi
On Thu, Oct 16, 2014 at 11:43 PM, philippedesw...@gmail.com wrote:
From: Philippe De Swert philippedesw...@gmail.com
Remove the following warning during the compilation:
src/libsystemd-terminal/grdev-drm.c: In function 'grdrm_card_hotplug':
src/libsystemd-terminal/grdev-drm.c:1087:45: warning: 'fb' may be used
uninitialized in this function [-Wmaybe-uninitialized]
src/libsystemd-terminal/grdev-drm.c:1035:19: note: 'fb' was declared here
---
src/libsystemd-terminal/grdev-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-terminal/grdev-drm.c
b/src/libsystemd-terminal/grdev-drm.c
index dba6db2..415755e 100644
--- a/src/libsystemd-terminal/grdev-drm.c
+++ b/src/libsystemd-terminal/grdev-drm.c
@@ -1032,7 +1032,7 @@ error:
static void grdrm_crtc_expose(grdrm_crtc *crtc) {
grdrm_pipe *pipe;
-grdrm_fb *fb;
+grdrm_fb *fb = NULL;
Ewww, this is not nice. It does fix the warning, indeed, but the
underlying problem is more generic. Lets look at this:
int some_function(void **out) {
...
r = ioctl(...);
if (r 0)
return -errno;
...
}
gcc has no guarantee that errno is 0 if r is 0. Therefore,
whenever it inlines those functions (-O2 etc.), it will spew a warning
that out might be uninitialized if r0 but errno==0. With -O0 gcc
doesn't complain as it probably does not optimize across functions.
However, with -O2 I get those warnings for static functions all the
time.
Not sure what to do here. I dislike initializing the pointer to NULL
as it might hide other real warnings. I'd prefer something like:
r = -SANE_ERRNO;
with:
#define SANE_ERRNO (abs(errno) ? : EMAGIC)
...not sure what we do in other places, though. Lennart? Tom?
Thanks
David
size_t i;
int r;
--
1.8.3.2
___
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 2/5] libsystemd:terminal :fix uninitialized warning
On Mon, Nov 3, 2014 at 1:12 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Thu, Oct 16, 2014 at 11:43 PM, philippedesw...@gmail.com wrote:
From: Philippe De Swert philippedesw...@gmail.com
Remove the following warning during the compilation:
src/libsystemd-terminal/grdev-drm.c: In function 'grdrm_card_hotplug':
src/libsystemd-terminal/grdev-drm.c:1087:45: warning: 'fb' may be used
uninitialized in this function [-Wmaybe-uninitialized]
src/libsystemd-terminal/grdev-drm.c:1035:19: note: 'fb' was declared here
---
src/libsystemd-terminal/grdev-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-terminal/grdev-drm.c
b/src/libsystemd-terminal/grdev-drm.c
index dba6db2..415755e 100644
--- a/src/libsystemd-terminal/grdev-drm.c
+++ b/src/libsystemd-terminal/grdev-drm.c
@@ -1032,7 +1032,7 @@ error:
static void grdrm_crtc_expose(grdrm_crtc *crtc) {
grdrm_pipe *pipe;
-grdrm_fb *fb;
+grdrm_fb *fb = NULL;
Ewww, this is not nice. It does fix the warning, indeed, but the
underlying problem is more generic. Lets look at this:
int some_function(void **out) {
...
r = ioctl(...);
if (r 0)
return -errno;
...
}
gcc has no guarantee that errno is 0 if r is 0. Therefore,
whenever it inlines those functions (-O2 etc.), it will spew a warning
that out might be uninitialized if r0 but errno==0. With -O0 gcc
doesn't complain as it probably does not optimize across functions.
However, with -O2 I get those warnings for static functions all the
time.
Not sure what to do here. I dislike initializing the pointer to NULL
as it might hide other real warnings. I'd prefer something like:
r = -SANE_ERRNO;
with:
#define SANE_ERRNO (abs(errno) ? : EMAGIC)
Hm, so if somehow errno == 0, we get some bogus errno?
...not sure what we do in other places, though. Lennart? Tom?
Will an assert do the trick? Something like
#define NERRNO (assert(errno 0), -errno)
Then we can replace every
r = foo();
if (r 0)
return -errno;
with
r = foo();
if (r 0)
return NERRNO;
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/5] libsystemd:terminal :fix uninitialized warning
On Mon, 03.11.14 13:12, David Herrmann (dh.herrm...@gmail.com) wrote:
Hi
On Thu, Oct 16, 2014 at 11:43 PM, philippedesw...@gmail.com wrote:
From: Philippe De Swert philippedesw...@gmail.com
Remove the following warning during the compilation:
src/libsystemd-terminal/grdev-drm.c: In function 'grdrm_card_hotplug':
src/libsystemd-terminal/grdev-drm.c:1087:45: warning: 'fb' may be used
uninitialized in this function [-Wmaybe-uninitialized]
src/libsystemd-terminal/grdev-drm.c:1035:19: note: 'fb' was declared here
---
src/libsystemd-terminal/grdev-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-terminal/grdev-drm.c
b/src/libsystemd-terminal/grdev-drm.c
index dba6db2..415755e 100644
--- a/src/libsystemd-terminal/grdev-drm.c
+++ b/src/libsystemd-terminal/grdev-drm.c
@@ -1032,7 +1032,7 @@ error:
static void grdrm_crtc_expose(grdrm_crtc *crtc) {
grdrm_pipe *pipe;
-grdrm_fb *fb;
+grdrm_fb *fb = NULL;
Ewww, this is not nice. It does fix the warning, indeed, but the
underlying problem is more generic. Lets look at this:
int some_function(void **out) {
...
r = ioctl(...);
if (r 0)
return -errno;
...
}
gcc has no guarantee that errno is 0 if r is 0. Therefore,
whenever it inlines those functions (-O2 etc.), it will spew a warning
that out might be uninitialized if r0 but errno==0. With -O0 gcc
doesn't complain as it probably does not optimize across functions.
However, with -O2 I get those warnings for static functions all the
time.
Not sure what to do here. I dislike initializing the pointer to NULL
as it might hide other real warnings. I'd prefer something like:
r = -SANE_ERRNO;
with:
#define SANE_ERRNO (abs(errno) ? : EMAGIC)
...not sure what we do in other places, though. Lennart? Tom?
So far we went the simple way out and merged patches like the original
one you are replying to.
Adding a call like this would make sane to me though:
static inline negative_errno(void) {
return _likely_(errno 0) ? -errno : -EINVAL;
}
Which is then invoked as:
return negative_errno();
or so...
Given that this stuff is executed only in the error code, the extra
complexity should not matter I guess.
I think it would be a mistake to simple negate already negative errno
codes, after all errno should never be negative itself...
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/5] libsystemd:terminal :fix uninitialized warning
On Mon, Nov 03, 2014 at 01:41:20PM +0100, Lennart Poettering wrote:
On Mon, 03.11.14 13:12, David Herrmann (dh.herrm...@gmail.com) wrote:
Hi
On Thu, Oct 16, 2014 at 11:43 PM, philippedesw...@gmail.com wrote:
From: Philippe De Swert philippedesw...@gmail.com
Remove the following warning during the compilation:
src/libsystemd-terminal/grdev-drm.c: In function 'grdrm_card_hotplug':
src/libsystemd-terminal/grdev-drm.c:1087:45: warning: 'fb' may be used
uninitialized in this function [-Wmaybe-uninitialized]
src/libsystemd-terminal/grdev-drm.c:1035:19: note: 'fb' was declared here
---
src/libsystemd-terminal/grdev-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-terminal/grdev-drm.c
b/src/libsystemd-terminal/grdev-drm.c
index dba6db2..415755e 100644
--- a/src/libsystemd-terminal/grdev-drm.c
+++ b/src/libsystemd-terminal/grdev-drm.c
@@ -1032,7 +1032,7 @@ error:
static void grdrm_crtc_expose(grdrm_crtc *crtc) {
grdrm_pipe *pipe;
-grdrm_fb *fb;
+grdrm_fb *fb = NULL;
Ewww, this is not nice. It does fix the warning, indeed, but the
underlying problem is more generic. Lets look at this:
int some_function(void **out) {
...
r = ioctl(...);
if (r 0)
return -errno;
...
}
gcc has no guarantee that errno is 0 if r is 0. Therefore,
whenever it inlines those functions (-O2 etc.), it will spew a warning
that out might be uninitialized if r0 but errno==0. With -O0 gcc
doesn't complain as it probably does not optimize across functions.
However, with -O2 I get those warnings for static functions all the
time.
Not sure what to do here. I dislike initializing the pointer to NULL
as it might hide other real warnings. I'd prefer something like:
r = -SANE_ERRNO;
with:
#define SANE_ERRNO (abs(errno) ? : EMAGIC)
...not sure what we do in other places, though. Lennart? Tom?
So far we went the simple way out and merged patches like the original
one you are replying to.
Adding a call like this would make sane to me though:
static inline negative_errno(void) {
return _likely_(errno 0) ? -errno : -EINVAL;
}
Which is then invoked as:
return negative_errno();
or so...
I like the assert more, because having errno = 0 would be a signficant bug
in the system, not something that we want to ever hide. So basically this
is a way to tell the compiler what we already know, and assert is better.
I also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846, but
without much response so far.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/5] libsystemd:terminal :fix uninitialized warning
Hi
On Mon, Nov 3, 2014 at 1:44 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Nov 03, 2014 at 01:41:20PM +0100, Lennart Poettering wrote:
On Mon, 03.11.14 13:12, David Herrmann (dh.herrm...@gmail.com) wrote:
Hi
On Thu, Oct 16, 2014 at 11:43 PM, philippedesw...@gmail.com wrote:
From: Philippe De Swert philippedesw...@gmail.com
Remove the following warning during the compilation:
src/libsystemd-terminal/grdev-drm.c: In function 'grdrm_card_hotplug':
src/libsystemd-terminal/grdev-drm.c:1087:45: warning: 'fb' may be used
uninitialized in this function [-Wmaybe-uninitialized]
src/libsystemd-terminal/grdev-drm.c:1035:19: note: 'fb' was declared here
---
src/libsystemd-terminal/grdev-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-terminal/grdev-drm.c
b/src/libsystemd-terminal/grdev-drm.c
index dba6db2..415755e 100644
--- a/src/libsystemd-terminal/grdev-drm.c
+++ b/src/libsystemd-terminal/grdev-drm.c
@@ -1032,7 +1032,7 @@ error:
static void grdrm_crtc_expose(grdrm_crtc *crtc) {
grdrm_pipe *pipe;
-grdrm_fb *fb;
+grdrm_fb *fb = NULL;
Ewww, this is not nice. It does fix the warning, indeed, but the
underlying problem is more generic. Lets look at this:
int some_function(void **out) {
...
r = ioctl(...);
if (r 0)
return -errno;
...
}
gcc has no guarantee that errno is 0 if r is 0. Therefore,
whenever it inlines those functions (-O2 etc.), it will spew a warning
that out might be uninitialized if r0 but errno==0. With -O0 gcc
doesn't complain as it probably does not optimize across functions.
However, with -O2 I get those warnings for static functions all the
time.
Not sure what to do here. I dislike initializing the pointer to NULL
as it might hide other real warnings. I'd prefer something like:
r = -SANE_ERRNO;
with:
#define SANE_ERRNO (abs(errno) ? : EMAGIC)
...not sure what we do in other places, though. Lennart? Tom?
So far we went the simple way out and merged patches like the original
one you are replying to.
Adding a call like this would make sane to me though:
static inline negative_errno(void) {
return _likely_(errno 0) ? -errno : -EINVAL;
}
Which is then invoked as:
return negative_errno();
or so...
I like the assert more, because having errno = 0 would be a signficant bug
in the system, not something that we want to ever hide. So basically this
is a way to tell the compiler what we already know, and assert is better.
Indeed. So how about:
static inline int negative_errno(void) {
assert_return(errno 0, -EINVAL);
return -errno;
}
Thanks
David
I also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846, but
without much response so far.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statelessy system
On Mon, Nov 03, 2014 at 12:24:42PM +0100, Lennart Poettering wrote: Would be happy to take a patch that makes those cases check for a config file in /usr/lib as fallback though, to cover all bases. Didn't we have a patch to support .d directories floated on the ml? Can't seem to find it at the moment. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] localectl: fix localectl set-x11-keymap syntax description
This complements the fix in commit cd4c6fb12598435fe24431f1dd616f9582f0e3b.
---
src/locale/localectl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/locale/localectl.c b/src/locale/localectl.c
index 3690f9f..d4a2d29 100644
--- a/src/locale/localectl.c
+++ b/src/locale/localectl.c
@@ -505,7 +505,7 @@ static void help(void) {
list-locales Show known locales\n
set-keymap MAP [MAP] Set virtual console keyboard
mapping\n
list-keymaps Show known virtual console keyboard
mappings\n
- set-x11-keymap LAYOUT [MODEL] [VARIANT] [OPTIONS]\n
+ set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]]\n
Set X11 keyboard mapping\n
list-x11-keymap-models Show known X11 keyboard mapping
models\n
list-x11-keymap-layouts Show known X11 keyboard mapping
layouts\n
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Add hidraw_id and a rule file to invoke it
Hi Andy,
On Tue, Oct 28, 2014 at 11:46 PM, Andy Lutomirski l...@amacapital.net wrote:
So far, hidraw_id detects U2F tokens and sets:
ID_U2F_TOKEN=1
ID_SECURITY_TOKEN=1
This causes the uaccess rules to apply to U2F devices.
---
I've never written any udev code before. Feedback welcome.
If you think this doesn't belong in udev, I can try to find it another home.
As mentioned, I don't think we should do this in core udev code (udev
rule would be ok), but making it generic and exposing all the usages
sounds useful. I don't have a strong opinion on whether this should be
in udev or in the kernel, but if you end up going with udev, here are
some comments.
Also, we don't want to add any more external helpers to the udev
codebase, so we should just make this a builtin (analogous to
udev-builtin-usb_id.c).
Minor comments inline.
[...]
diff --git a/src/udev/hidraw_id/hidraw_id.c b/src/udev/hidraw_id/hidraw_id.c
new file mode 100644
index ..e32f222f22f9
--- /dev/null
+++ b/src/udev/hidraw_id/hidraw_id.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) Andrew Lutomirski, 2014
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
New udev code must be LGPL2+.
[...]
+int main(int argc, char **argv)
+{
+struct udev *udev;
+struct udev_device *dev, *hiddev;
+char path[4096];
Maybe, avoid hardcoding the length, and use _cleaunp_free_ char *path
= NULL; and asprintf() like in the other builtins?
+unsigned char desc[4096];
I guess we can use unsigned char desc[HID_MAX_DESCRIPTOR_SIZE]; here?
[...]
+/* Parse the report descriptor. */
+for (i = 0; i desclen; ) {
+unsigned char tag = desc[i] 4;
+unsigned char type = (desc[i] 2) 0x3;
+unsigned char sizecode = desc[i] 0x3;
+int size, j;
+unsigned int value = 0;
+
+if (desc[i] == 0xfe) {
Please introduce defines for any magic constants to make the code a
bit more self-documenting.
#define HIDRAW_REPORT_DESCRIPTOR_LONG_ITEM 0xfe
Same below, please introduce something like
#define HIDRAW_REPORT_DESCRIPTOR_TYPE_GLOBAL 0x1
#define HIDRAW_REPORT_DESCRIPTOR_TYPE_LOCAL 0x2
#define HIDRAW_REPORT_DESCRIPTOR_GLOBAL_ITEM_USAGE_PAGE 0x0
#define HIDRAW_REPORT_DESCRIPTOR_LOCAL_ITEM_USAGE 0x0
(you can probably think of better/shorter names though).
+/* Long item; skip it. */
+if (i + 1 = desclen) {
+log_error(bad report_descriptor);
+goto out;
+}
+i += (desc[i+1] + 3); /* Can't overflow. */
+continue;
+}
+
+size = (sizecode 3 ? sizecode : 4);
+
+if (i + 1 + size desclen) {
+log_error(bad report_descriptor);
+goto out;
+}
+
+for (j = 0; j size; j++)
+value |= (desc[i + 1 + j] 8*j);
+
+if (type == 1 tag == 0)
+usage_page = value;
Should we verify that the data has the right length (2 or 4 bytes)? I
guess we also need to handle 2-byte usage pages specially?
+
+/*
+ * Detect U2F tokens. See:
+ *
https://fidoalliance.org/specs/fido-u2f-HID-protocol-v1.0-rd-20141008.pdf
+ * http://www.usb.org/developers/hidpage/HUTRR48.pdf
+ */
+
+if (type == 2 tag == 0) {
+if (usage_page == 0xf1d0 value == 0x1)
+is_u2f_token = 1;
+}
+
+i += 1 + size;
+}
[...]
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Properly define the __NR_memfd_create macro for MIPS
This macro exists for MIPS since v3.17:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=42944521af97a3b25516f15f3149aec3779656dc
Signed-off-by: Vicente Olivert Riera vincent.ri...@imgtec.com
---
src/shared/missing.h | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/shared/missing.h b/src/shared/missing.h
index 0d7c559..cccab46 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -125,8 +125,15 @@ static inline int pivot_root(const char *new_root, const
char *put_old) {
# elif defined __arm__
#define __NR_memfd_create 385
# elif defined _MIPS_SIM
-#warning __NR_memfd_create not yet defined for MIPS
-#define __NR_memfd_create 0x
+#if _MIPS_SIM == _MIPS_SIM_ABI32
+# define __NR_memfd_create 4354
+#endif
+#if _MIPS_SIM == _MIPS_SIM_NABI32
+# define __NR_memfd_create 6318
+#endif
+#if _MIPS_SIM == _MIPS_SIM_ABI64
+# define __NR_memfd_create 5314
+#endif
# else
#define __NR_memfd_create 356
# endif
--
1.7.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Put user@.service cgroups into all controllers (user LXC)
Hello all, LXC upstream (in CC:) supports unprivileged containers, i. e. you can create a rootfs in your $HOME and then run lxc-start on it with some initial preparation [1]. While of course they have some limits, they are very useful for a lot of applications and are by nature quite safe towards other users/containers/services on the same machine. However, that requires putting at least the per-user session cgroup (from logind) into *all* available cgroup controllers, not just the systemd one, so that the per-user container actually has privileges to create sub-cgroups under the session-cN.scope parent. Thus this currently only works with cgmanager (which creates all cgroups that way) or with systemd = 204, which had the Controllers option in logind.conf: Controllers=blkio cpu cpuacct cpuset devices freezer hugetlb memory perf_event net_cls net_prio This certainly wasn't pretty, but it did the job. This option went away from later versions with moving to calling pid1's StartTransientUnit() [2]. I'd like to get this functionality back, to eliminate another blocker for switching Ubuntu to systemd by default, and would like to pick your brain what you'd recommend as a solution. Note: this isn't Ubuntu specific at all, just a generic question whether systemd wants to support LXC's per-user containers, and whether potentially changing the default behaviour would collide with anything else systemd wants (or doesn't want to) do. AFAIUI, the consequence of just always adding the session-cN.scope into all controllers is mostly a very small performance penalty due to the additional cgroup translations. If there are reasons to not do this by default, the other options would be to (re-)introduce some config option (which would certainly look different now, as logind cgroups are now not particularly special compared to other service cgroups), or carrying a downstream patch (least preferred of course, but if necessary we'll have to do that -- we don't want to regress LXC). Hints are appreciated. Thanks! Martin [1] https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ [2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=fb6becb4436ae -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Put user@.service cgroups into all controllers (user LXC)
On 11/03/2014 03:25 PM, Martin Pitt wrote: Hints are appreciated. Thanks! Assuming you have read [1] Is not the solution to this problem to simply drop systemd-shim and cgmanager and just use systemd? 1. http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
Hi On Wed, Oct 29, 2014 at 3:45 PM, Bastien Nocera had...@hadess.net wrote: For a very specific definition of inactive. I'm looking at a way for the iio-sensor-proxy at: https://github.com/hadess/iio-sensor-proxy to suspend reading from accelerometers (or maybe to turn them off), when all the sessions are locked and the screens turned off. This would usually mean that I would enable reading from the sensor if one session is active and stop reading if none are active. Is this correct? Is it up to the session manager (eg. gnome-session) to tell us whether a session is active or not, or do I have this backwards? For uhid (similar to uinput) you get an OPEN and CLOSE event whenever the first/last user opens/closes the device you created. I think we want something similar for uinput. That is, when a gnome session is inactive, they should just close the input devices that were created by iio-sensor-proxy (done automatically if you use the systemd-logind API to access devices). This way, iio-sensor-proxy knows whenever at least one session uses the data. This is also how most kernel-internal APIs work. This way, iio-sensor-proxy would get an OPEN event if at least one user reads the data it produces, and a CLOSE event once the last user closed the device. Unfortunately, this requires kernel changes, which you probably want to avoid. But a user-space solution sounds like a hack to me. You'd have to somehow 'guess' whether there's a user of your input device. Not sure how to make that reliable.. I wrote something up: https://gist.github.com/dvdhrm/6af5b000ddaed781764c I can try to send this to linux-input@vger today. One downside is that there's no way to synchronously query iio-sensor-proxy to provide the needed information on wake-up. That is, if the screen is turned on but iio-sensor-proxy is suspended, then the first frame might be displayed in the wrong layout. If iio-sensor-proxy was a kernel driver, this wouldn't happen. Similarly, if it provided a dbus API, gnome could query it synchronously on wake-up. I could make the UI_EV_OPEN event synchronous, but that seems overkill to me... hmm, not sure. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Put user@.service cgroups into all controllers (user LXC)
Jóhann B. Guðmundsson [2014-11-03 16:20 +]: Assuming you have read [1] Is not the solution to this problem to simply drop systemd-shim and cgmanager and just use systemd? For the most part, this can't be retroactively done for stable releases (for the container payloads). Also, I think running systemd as pid 1 in user containers is not currently working, but Stéphane has more details about that. 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] Put user@.service cgroups into all controllers (user LXC)
On Nov 3, 2014 8:21 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/03/2014 03:25 PM, Martin Pitt wrote: Hints are appreciated. Thanks! Assuming you have read [1] Is not the solution to this problem to simply drop systemd-shim and cgmanager and just use systemd? His message is how the behavior they are relying on in cgmgr is not what systemd gives, and how that is causing problems with unpriveleged LXC containers. So no, I do not think so. Regards, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting inactive sessions
On Mon, 2014-11-03 at 17:28 +0100, David Herrmann wrote: Hi On Wed, Oct 29, 2014 at 3:45 PM, Bastien Nocera had...@hadess.net wrote: For a very specific definition of inactive. I'm looking at a way for the iio-sensor-proxy at: https://github.com/hadess/iio-sensor-proxy to suspend reading from accelerometers (or maybe to turn them off), when all the sessions are locked and the screens turned off. This would usually mean that I would enable reading from the sensor if one session is active and stop reading if none are active. Is this correct? Is it up to the session manager (eg. gnome-session) to tell us whether a session is active or not, or do I have this backwards? For uhid (similar to uinput) you get an OPEN and CLOSE event whenever the first/last user opens/closes the device you created. I think we want something similar for uinput. That is, when a gnome session is inactive, they should just close the input devices that were created by iio-sensor-proxy (done automatically if you use the systemd-logind API to access devices). This way, iio-sensor-proxy knows whenever at least one session uses the data. This is also how most kernel-internal APIs work. The session doesn't read from the uinput device. The iio-sensor-proxy just sends out a kevent, which is caught by the accelerometer helper in udev. The GNOME session catches the udev event and reads the changed property. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl user start Xorg
Perhaps /etc/X11/Xwrapper.config needs_root_rights = auto allowed_users = anybody I placed the Xwrapper.config, but the xorg.service still fails My unit files : $XDG_CONFIG_HOME/systemd/user/xorg.service [Unit] Description=Xorg server at display :0 Requires=xorg.socket After=xorg.socket [Service] ExecStart=/usr/bin/Xorg.bin -nolisten tcp :0 vt1 [Install] WantedBy=wm.target $XDG_CONFIG_HOME/systemd/user/xorg.socket [Unit] Description=Xorg Server Socket [Socket] ListenStream=/tmp/.X11-unix/X0 [Install] WantedBy=sockets.target $ systemctl --user status xorg ● xorg.service - Xorg server at display :0 Loaded: loaded (/home/gabx/.config/systemd/user/xorg.service; enabled) Active: failed (Result: start-limit) since Mon 2014-11-03 17:40:09 CET; 2min 0s ago Process: 825 ExecStart=/usr/bin/Xorg.bin -nolisten tcp :0 vt1 (code=exited, status=1/FAILURE) Main PID: 825 (code=exited, status=1/FAILURE) Nov 03 17:40:09 hortensia Xorg.bin[825]: (EE) Nov 03 17:40:09 hortensia Xorg.bin[825]: Please consult the The X.Org Foundation support Nov 03 17:40:09 hortensia Xorg.bin[825]: at http://wiki.x.org Nov 03 17:40:09 hortensia Xorg.bin[825]: for help. Nov 03 17:40:09 hortensia systemd[759]: xorg.service: main process exited, code=exited, status=1/FAILURE Nov 03 17:40:09 hortensia systemd[759]: Failed to start Xorg server at display :0. Nov 03 17:40:09 hortensia systemd[759]: Unit xorg.service entered failed state. Nov 03 17:40:09 hortensia systemd[759]: Starting Xorg server at display :0... Nov 03 17:40:09 hortensia systemd[759]: xorg.service start request repeated too quickly, refusing to start. Nov 03 17:40:09 hortensia systemd[759]: Failed to start Xorg server at display :0. Xorg.0.log --- ... [ 5.471] (++) using VT number 1 [ 5.471] (WW) xf86OpenConsole: setpgid failed: Operation not permitted [ 5.471] (WW) xf86OpenConsole: setsid failed: Operation not permitted [ 5.471] (EE) Fatal server error: [ 5.471] (EE) xf86OpenConsole: Cannot open virtual console 1 (Permission denied) [ 5.471] (EE) Thank you for any suggestions ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Add hidraw_id and a rule file to invoke it
On Mon, Nov 3, 2014 at 5:32 AM, Tom Gundersen t...@jklm.no wrote:
Hi Andy,
On Tue, Oct 28, 2014 at 11:46 PM, Andy Lutomirski l...@amacapital.net wrote:
So far, hidraw_id detects U2F tokens and sets:
ID_U2F_TOKEN=1
ID_SECURITY_TOKEN=1
This causes the uaccess rules to apply to U2F devices.
---
I've never written any udev code before. Feedback welcome.
If you think this doesn't belong in udev, I can try to find it another home.
As mentioned, I don't think we should do this in core udev code (udev
rule would be ok), but making it generic and exposing all the usages
sounds useful. I don't have a strong opinion on whether this should be
in udev or in the kernel, but if you end up going with udev, here are
some comments.
Thanks. I'll wait to see what Jiri thinks before sending an updated version.
Also, we don't want to add any more external helpers to the udev
codebase, so we should just make this a builtin (analogous to
udev-builtin-usb_id.c).
Minor comments inline.
[...]
diff --git a/src/udev/hidraw_id/hidraw_id.c b/src/udev/hidraw_id/hidraw_id.c
new file mode 100644
index ..e32f222f22f9
--- /dev/null
+++ b/src/udev/hidraw_id/hidraw_id.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) Andrew Lutomirski, 2014
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
New udev code must be LGPL2+.
OK.
[snipped things I'll change if I resubmit]
+/* Long item; skip it. */
+if (i + 1 = desclen) {
+log_error(bad report_descriptor);
+goto out;
+}
+i += (desc[i+1] + 3); /* Can't overflow. */
+continue;
+}
+
+size = (sizecode 3 ? sizecode : 4);
+
+if (i + 1 + size desclen) {
+log_error(bad report_descriptor);
+goto out;
+}
+
+for (j = 0; j size; j++)
+value |= (desc[i + 1 + j] 8*j);
+
+if (type == 1 tag == 0)
+usage_page = value;
Should we verify that the data has the right length (2 or 4 bytes)? I
guess we also need to handle 2-byte usage pages specially?
I think we're not supposed to check the length in general, but I
should re-read the part about two-byte usage pages. (Although, off
the top of my head, I thought that the special case was for very long
usages, not usage pages.)
[...]
--Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statelessy system
Zbigniew Jędrzejewski-Szmek wrote: On Mon, Nov 03, 2014 at 12:24:42PM +0100, Lennart Poettering wrote: Would be happy to take a patch that makes those cases check for a config file in /usr/lib as fallback though, to cover all bases. Didn't we have a patch to support .d directories floated on the ml? Can't seem to find it at the moment. Yes, I posted one for logind.conf.d; see message IDs 20141029120251.GA30088@thin ([PATCH 1/2] Introduce CONF_DIRS_NULSTR helper to define standard conf dirs) and 20141029121045.GA5365@thin ([PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths). http://lists.freedesktop.org/archives/systemd-devel/2014-October/024676.html http://lists.freedesktop.org/archives/systemd-devel/2014-October/024677.html I'd love to see those applied. If those work for you, I can produce additional patches for the other config files in /etc/systemd. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] [PATCH] cgroup: don't trim cgroup trees created by someone else
On Tue, Oct 21, 2014 at 09:16:16PM +0200, Lennart Poettering wrote: On Fri, 19.09.14 17:14, Michal Sekletar (msekl...@redhat.com) wrote: snip I do see the usecase though for those projects. I'd probably suggest not to merge it for RHEL either. But instead I'd propose a different solution for software: make sure sure to always move a PID into a cgroup as soon as it is created, so that its removal is blocked. Or in other words: right before you need a cgroup to add yourself to it, create it, and expect that it might go away while you are not using it. To deal with the possible race condition of creating a cgroup which is immediately cleaned up by somebody else, try doing this in a loop, until you succeeded. I think I grok what are you proposing, however according to developments in https://bugzilla.redhat.com/show_bug.cgi?id=1139223 it doesn't seem to be correct solution either. systemd will happily remove cgroup in which there are processes. That way things can always stay nicely cleaned up and things are robust towards other processing playing around in the cgroup tree. I am not sure how can we make that possible (playing nicely in cgroup tree) for the time beeing until we are the only writer. Hope that makes sense? Lennart Michal -- 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] localectl: fix localectl set-x11-keymap syntax description
Hi
On Mon, Nov 3, 2014 at 2:01 PM, Jan Synacek jsyna...@redhat.com wrote:
This complements the fix in commit cd4c6fb12598435fe24431f1dd616f9582f0e3b.
Applied!
Thanks
David
---
src/locale/localectl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/locale/localectl.c b/src/locale/localectl.c
index 3690f9f..d4a2d29 100644
--- a/src/locale/localectl.c
+++ b/src/locale/localectl.c
@@ -505,7 +505,7 @@ static void help(void) {
list-locales Show known locales\n
set-keymap MAP [MAP] Set virtual console keyboard
mapping\n
list-keymaps Show known virtual console
keyboard mappings\n
- set-x11-keymap LAYOUT [MODEL] [VARIANT] [OPTIONS]\n
+ set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]]\n
Set X11 keyboard mapping\n
list-x11-keymap-models Show known X11 keyboard mapping
models\n
list-x11-keymap-layouts Show known X11 keyboard mapping
layouts\n
--
1.9.3
___
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] udev: Add hidraw_id and a rule file to invoke it
On Mon, Nov 3, 2014 at 5:47 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Nov 3, 2014 at 5:32 AM, Tom Gundersen t...@jklm.no wrote:
Hi Andy,
On Tue, Oct 28, 2014 at 11:46 PM, Andy Lutomirski l...@amacapital.net
wrote:
So far, hidraw_id detects U2F tokens and sets:
ID_U2F_TOKEN=1
ID_SECURITY_TOKEN=1
This causes the uaccess rules to apply to U2F devices.
---
I've never written any udev code before. Feedback welcome.
If you think this doesn't belong in udev, I can try to find it another home.
As mentioned, I don't think we should do this in core udev code (udev
rule would be ok), but making it generic and exposing all the usages
sounds useful. I don't have a strong opinion on whether this should be
in udev or in the kernel, but if you end up going with udev, here are
some comments.
Thanks. I'll wait to see what Jiri thinks before sending an updated version.
Also, we don't want to add any more external helpers to the udev
codebase, so we should just make this a builtin (analogous to
udev-builtin-usb_id.c).
Minor comments inline.
[...]
diff --git a/src/udev/hidraw_id/hidraw_id.c b/src/udev/hidraw_id/hidraw_id.c
new file mode 100644
index ..e32f222f22f9
--- /dev/null
+++ b/src/udev/hidraw_id/hidraw_id.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) Andrew Lutomirski, 2014
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
New udev code must be LGPL2+.
OK.
[snipped things I'll change if I resubmit]
+/* Long item; skip it. */
+if (i + 1 = desclen) {
+log_error(bad report_descriptor);
+goto out;
+}
+i += (desc[i+1] + 3); /* Can't overflow. */
+continue;
+}
+
+size = (sizecode 3 ? sizecode : 4);
+
+if (i + 1 + size desclen) {
+log_error(bad report_descriptor);
+goto out;
+}
+
+for (j = 0; j size; j++)
+value |= (desc[i + 1 + j] 8*j);
+
+if (type == 1 tag == 0)
+usage_page = value;
Should we verify that the data has the right length (2 or 4 bytes)? I
guess we also need to handle 2-byte usage pages specially?
I think we're not supposed to check the length in general, but I
should re-read the part about two-byte usage pages. (Although, off
the top of my head, I thought that the special case was for very long
usages, not usage pages.)
Ah, you are right. usage_page should always be 2 bytes, and usage can
be 4 bytes or less.
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Properly define the __NR_memfd_create macro for MIPS
Hi
On Mon, Nov 3, 2014 at 3:48 PM, Vicente Olivert Riera
vincent.ri...@imgtec.com wrote:
This macro exists for MIPS since v3.17:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=42944521af97a3b25516f15f3149aec3779656dc
Signed-off-by: Vicente Olivert Riera vincent.ri...@imgtec.com
No s-o-b needed. I dropped it.
Applied!
Thanks
David
---
src/shared/missing.h | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/shared/missing.h b/src/shared/missing.h
index 0d7c559..cccab46 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -125,8 +125,15 @@ static inline int pivot_root(const char *new_root, const
char *put_old) {
# elif defined __arm__
#define __NR_memfd_create 385
# elif defined _MIPS_SIM
-#warning __NR_memfd_create not yet defined for MIPS
-#define __NR_memfd_create 0x
+#if _MIPS_SIM == _MIPS_SIM_ABI32
+# define __NR_memfd_create 4354
+#endif
+#if _MIPS_SIM == _MIPS_SIM_NABI32
+# define __NR_memfd_create 6318
+#endif
+#if _MIPS_SIM == _MIPS_SIM_ABI64
+# define __NR_memfd_create 5314
+#endif
# else
#define __NR_memfd_create 356
# endif
--
1.7.1
___
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] Put user@.service cgroups into all controllers (user LXC)
On Mon, Nov 3, 2014 at 8:32 AM, Cameron Norman camerontnor...@gmail.com wrote: On Nov 3, 2014 8:21 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/03/2014 03:25 PM, Martin Pitt wrote: Hints are appreciated. Thanks! Assuming you have read [1] Is not the solution to this problem to simply drop systemd-shim and cgmanager and just use systemd? His message is how the behavior they are relying on in cgmgr is not what systemd gives, and how that is causing problems with unpriveleged LXC containers. So no, I do not think so. I apologize. I did not realize you meant swapping cgmanager for systemd in the guest; I thought you were referring to the host. Regards, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
Hi On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. [snip] - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Imho, this is the way to go. Create a proper char-dev for U2F, create an API and make it work. We had this discussion earlier about vendor-extensions that should be writable via hidraw from user-space. This turned out to be really messy.. and was discussed for several weeks straight. hidraw just wasn't designed as unprivileged user-space API. For instance, what happens if a device provides U2F plus something else? Both will be on the same hidraw device. We could split hidraw per usage, but I don't see how that is superior to a proper U2F API. And once one usage can affect a device as a whole (like power-off), you're screwed. Just look at the libusb mess where some devices are handled in the kernel and some in user-space (eg., see Gnome cheese, media devices, ...). I don't think we should repeat that with HID. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, Nov 3, 2014 at 11:03 AM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. [snip] - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Imho, this is the way to go. Create a proper char-dev for U2F, create an API and make it work. We had this discussion earlier about vendor-extensions that should be writable via hidraw from user-space. This turned out to be really messy.. and was discussed for several weeks straight. hidraw just wasn't designed as unprivileged user-space API. For instance, what happens if a device provides U2F plus something else? Both will be on the same hidraw device. We could split hidraw per usage, but I don't see how that is superior to a proper U2F API. And once one usage can affect a device as a whole (like power-off), you're screwed. Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. --Andy Just look at the libusb mess where some devices are handled in the kernel and some in user-space (eg., see Gnome cheese, media devices, ...). I don't think we should repeat that with HID. Thanks David -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
Hi On Mon, Nov 3, 2014 at 8:19 PM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Nov 3, 2014 at 11:03 AM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. [snip] - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Imho, this is the way to go. Create a proper char-dev for U2F, create an API and make it work. We had this discussion earlier about vendor-extensions that should be writable via hidraw from user-space. This turned out to be really messy.. and was discussed for several weeks straight. hidraw just wasn't designed as unprivileged user-space API. For instance, what happens if a device provides U2F plus something else? Both will be on the same hidraw device. We could split hidraw per usage, but I don't see how that is superior to a proper U2F API. And once one usage can affect a device as a whole (like power-off), you're screwed. Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. Alright, I am basically thinking loudly now, but how about we allow HID drivers that would override default hidraw interface? I am very well aware of the fact that this could be opening a can of worms, so we'll have to make it very restrictive. How about, let's say, we allow HID drivers to provide custom hidraw interface (completely overriding the one that HID core would normally create) only for cases such as: - the intent is to expose only certain parts of a combined device - the intent is to introduce some level of access control I.e. still no interference of kernel with data parsing allowed. I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Same here, of course. Please always CC me in parallel to sending to linux-input@ to make sure that the patch doesn't fall in between cracks. Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina jkos...@suse.cz wrote: On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. Alright, I am basically thinking loudly now, but how about we allow HID drivers that would override default hidraw interface? I am very well aware of the fact that this could be opening a can of worms, so we'll have to make it very restrictive. How about, let's say, we allow HID drivers to provide custom hidraw interface (completely overriding the one that HID core would normally create) only for cases such as: - the intent is to expose only certain parts of a combined device - the intent is to introduce some level of access control I.e. still no interference of kernel with data parsing allowed. Hmm. Would this be like a filter on hidraw actions? How would udev distinguish these special hidraw devices from normal hidraw devices? Also, for U2F, this could be a little awkward. There's some crazy fragmentation stuff to allow a U2F request to be split across HID requests, and I think a kernel driver would much rather get the original unfragmented application request. --Andy I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Same here, of course. Please always CC me in parallel to sending to linux-input@ to make sure that the patch doesn't fall in between cracks. Thanks, -- Jiri Kosina SUSE Labs -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] localectl: fix localectl set-x11-keymap syntax description
David Herrmann dh.herrm...@gmail.com writes:
Hi
On Mon, Nov 3, 2014 at 2:01 PM, Jan Synacek jsyna...@redhat.com wrote:
This complements the fix in commit cd4c6fb12598435fe24431f1dd616f9582f0e3b.
Applied!
I don't think it was, I can't see the patch anywhere in the logs.
Thanks
David
---
src/locale/localectl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/locale/localectl.c b/src/locale/localectl.c
index 3690f9f..d4a2d29 100644
--- a/src/locale/localectl.c
+++ b/src/locale/localectl.c
@@ -505,7 +505,7 @@ static void help(void) {
list-locales Show known locales\n
set-keymap MAP [MAP] Set virtual console keyboard
mapping\n
list-keymaps Show known virtual console
keyboard mappings\n
- set-x11-keymap LAYOUT [MODEL] [VARIANT] [OPTIONS]\n
+ set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]]\n
Set X11 keyboard mapping\n
list-x11-keymap-models Show known X11 keyboard mapping
models\n
list-x11-keymap-layouts Show known X11 keyboard mapping
layouts\n
--
1.9.3
--
Jan Synacek
Software Engineer, Red Hat
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] localectl: fix localectl set-x11-keymap syntax description
Hi On Tue, Nov 4, 2014 at 8:13 AM, Jan Synacek jsyna...@redhat.com wrote: David Herrmann dh.herrm...@gmail.com writes: Hi On Mon, Nov 3, 2014 at 2:01 PM, Jan Synacek jsyna...@redhat.com wrote: This complements the fix in commit cd4c6fb12598435fe24431f1dd616f9582f0e3b. Applied! I don't think it was, I can't see the patch anywhere in the logs. I applied it locally. freedesktop.org wasn't reachable yesterday evening, so I couldn't push it out. I've done that now. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
