Re: [systemd-devel] [PATCH] Drop the udev firmware loader
El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30 May 2014 03:10, Michael Biebl mbi...@gmail.com wrote: 2014-05-30 3:55 GMT+02:00 Greg KH gre...@linuxfoundation.org: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? Debian Wheezy does ship with 3.2 and we do provide backports of newer systemd versions of it. It also simplifies dist-upgrades if one can still boot with the old kernel in case the new one fails to boot for whatever reason. So +1 for keeping it. As Zbiginiew said, the maintenance cost is basically zero. While it is not very important that this patch gets applied now, as a general rule it seems extremely unlikely that we will keep being able to boot on such old kernels going forward. Maybe it would be best to find some alternative way to achieve your features sooner rather than later? You could for instance use the double reboot mechanism to upgrade from really old kernels and some sort of double buffering or snapshots to support rollback. Running new user space on ancient kernels seems like it would just cause more work at little to no gain... Just my two cents, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
On Fri, May 30, 2014 at 3:24 AM, Camilo Aguilar camilo.agui...@gmail.com wrote: Hi Tom, the patch did not work because there is no layer2 file. Would it be safe to assume that no file is the same as the file having 0? This is out of my reach unfortunately, but I will be happy to read whatever link you throw at me. I don't think that would work, as only the qeth driver actually exposes the layer2 file (and to the best of my knowledge the other upstream drivers support unicast). If other drivers also can't do unicast, then they need to expose this information to us somehow, I'm afraid that I don't know anything about the VMWare driver, but hopefully we can find a way to get this info out of that driver too (would of course be nice if everyone used the same interface...). Also, to better clarify how ISC dhcp-4.3.0 works. It seems it uses raw sockets as a first attempt (layer2 unicast) and falls back to normal BSD sockets which will always set the broadcast flag on: https://cloudup.com/cAneyImU2H2 and https://gist.github.com/c4milo/017a50a6f5d329887707 I'd really hope we could avoid setting broadcast everywhere, as that seems very wasteful... Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
On Thu, 2014-05-29 at 00:03 +0100, Tom Gundersen wrote: On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar camilo.agui...@gmail.com wrote: In systems running on hypervisors this flag needs to be set ON, so offers can reach the virtual machines. For more information please refer to this thread in CoreOS: https://github.com/coreos/bugs/issues/12 Signed-off-by: Camilo Aguilar camilo.agui...@gmail.com --- src/libsystemd-network/sd-dhcp-client.c | 9 + 1 file changed, 9 insertions(+) diff --git a/src/libsystemd-network/sd-dhcp-client.c b/src/libsystemd-network/sd-dhcp-client.c index 0300a6b..8f54906 100644 --- a/src/libsystemd-network/sd-dhcp-client.c +++ b/src/libsystemd-network/sd-dhcp-client.c @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client *client, DHCPPacket **ret, refuse to issue an DHCP lease if 'secs' is set to zero */ packet-dhcp.secs = htobe16(client-secs); +/* RFC2132 section 4.1 + A client that cannot receive unicast IP datagrams until its protocol + software has been configured with an IP address SHOULD set the + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or + DHCPREQUEST messages that client sends. The BROADCAST bit will + provide a hint to the DHCP server and BOOTP relay agent to broadcast + any messages to the client on the client's subnet. */ +packet-dhcp.flags = htobe16(0x8000); Hm, most clients can and should use unicast, so we should definitely not request broadcast unconditionally. If there really is a situation where we need broadcast, we should detect that and only request broadcast in this case. Does that make sense? Actually, I have had recent reports from users that there seems to exist a category of networking devices which discard DHCPv4 messages unless the messages are sent by broadcast. The users say that forcing the DHCPv4 clients to use broadcast fixes the problem. I recently added a patch to ConnMan that always requests broadcast replies when it is sending broadcast itself. That means broadcast DHCPDiscover - DHCPOffer messages as well as DHCPRequest - DHCPAck/Nak messages in Requesting and Rebinding states. Unicast is used for most of the normal message sending in the Renewing state. This way not every message is broadcast and if unicast messages disappear, there is always Rebinding that gets through before lease expiry. Should we do the same thing in networkd? Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
On Thu, 2014-05-29 at 18:18 +0100, Tom Gundersen wrote:
+ if (link-udev_device) {
+ const char *l2;
+
+ l2 = udev_device_get_sysattr_value(link-udev_device, layer2);
+ if (l2) {
+ unsigned layer2;
+
+ r = safe_atou(l2, layer2);
+ if (r 0)
+ return r;
+
+ if (!layer2) {
+ r = sd_dhcp_client_request_broadcast(link-dhcp_client);
+ if (r 0)
+ return r;
+ }
Am I now missing something if I can't find the
file /sys/class/net/device/device/layer2 for a regular networking
interface? The above enables broadcast only for virtual interfaces,
right?
Cheers,
Patrik
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30/05/14 09:17, Cristian Rodríguez wrote: El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... You are right, this fhandle business is new, but we have 208 for kernels with no CONFIG_FHANDLE, and 212/213 for ones without, I have plans on keeping 208 for a long time in tree (it's on my TODO list to apply the patch that adds CONFIG_FHANDLE to our special kernel sources, but it's not done yet) We have embedded uses for eg. Genesis Efika MX (arm neon processor) with special kernel patches 2.6.32.* series, just to name one I personally use, and I know we have more of these uses, all ARM related But seriously, if at all possible, please keep the firmware thing for like this year in the code, it would be greately appericiated - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] git requires now linux api userspace headers = 3.13 to build?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31.03.2014 17:18, Tom Gundersen wrote:
I remember reading a while back here = 3.7 being required and
that being reworked to not require so new, but looks like
something backfired there...
Ah, my bad. I did the rework, but forgot to put in the #ifdef's.
Will do.
The following errors seem to imply = 3.10 is now required (which
wouldn't match with the README) - or that this older issue hasn't been
fixed completely (because the 3.8 headers were being used):
Makefile:11905: recipe for target
'src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo' failed
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:70:10:
error: 'IFLA_VLAN_PROTOCOL' undeclared here (not in a function)
[IFLA_VLAN_PROTOCOL]= { .type = NLA_U16 },
^
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:70:9:
error: array index in initializer not of integer type
[IFLA_VLAN_PROTOCOL]= { .type = NLA_U16 },
^
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:70:9:
error: (near initialization for 'rtnl_link_info_data_vlan_types')
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:231:9:
error: array index in initializer exceeds array bounds
[IFLA_CARRIER] = { .type = NLA_U8 },
^
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:231:9:
error: (near initialization for 'rtnl_link_types')
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:231:9:
warning: excess elements in array initializer [enabled by default]
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:231:9:
warning: (near initialization for 'rtnl_link_types') [enabled by default]
make[2]: ***
[src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo] Error 1
- --
Best regards, Wulf
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOIWAcACgkQnuVXRcSi+5orSQCfbiPrFGwzpPwXW38U7BzHwp/r
rDkAoKEE2X47VPKfK2W1KD9hM58RvBed
=W2ca
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 05/30/2014 02:51 AM, Greg KH wrote: On Fri, May 30, 2014 at 04:41:01AM +0200, Michael Biebl wrote: 2014-05-30 4:32 GMT+02:00 Michael Bieblmbi...@gmail.com: 2014-05-30 4:26 GMT+02:00 Greg KHgre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. What I'm trying to say here is: let's rip this code out once all stable distros out there in the wild ship a kernel with builti-in firmware loader support, but please not before. What is all? Do we really have to wait 10+ years just because some random disto doesn't want to update their kernel? Since when does systemd care about what random distros do? Agreed. Upstream should always be the driving force forwards thus carrying the most modern code as well as being the decisive factor when it's time to obsolete things from their code base and the burden be put on downstream to carry and maintaining the legacy code being removed if for whatever reason they still require the functionality it provided, be it the udev firmware loader or legacy compatibility mode or generators etc. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journald: collect process data from socket data
This patch adds posibility for journal to get process data from
socket data (if available) instead of from procfs.
Additionally a new procinfo structure is added to store all process
data in single place. This data include creditentials and status.
To enable this functionality, SO_PASSPROC socket option must be set.
This option is introduced in:
http://lwn.net/Articles/600564/
With this patch journald cpu usage is decresed by about 20%
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
---
src/journal/journald-kmsg.c | 2 +-
src/journal/journald-native.c | 24
src/journal/journald-native.h | 4 +-
src/journal/journald-server.c | 131 +-
src/journal/journald-server.h | 17 +-
src/journal/journald-stream.c | 7 ++-
src/journal/journald-syslog.c | 15 +++--
src/journal/journald-syslog.h | 2 +-
8 files changed, 155 insertions(+), 47 deletions(-)
diff --git a/src/journal/journald-kmsg.c b/src/journal/journald-kmsg.c
index 12992e7..0bac0df 100644
--- a/src/journal/journald-kmsg.c
+++ b/src/journal/journald-kmsg.c
@@ -304,7 +304,7 @@ static void dev_kmsg_record(Server *s, char *p, size_t l) {
if (message)
IOVEC_SET_STRING(iovec[n++], message);
-server_dispatch_message(s, iovec, n, ELEMENTSOF(iovec), NULL, NULL,
NULL, 0, NULL, priority, 0);
+server_dispatch_message(s, iovec, n, ELEMENTSOF(iovec), NULL, NULL,
priority, 0);
finish:
for (j = 0; j z; j++)
diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
index c54f647..b2c44d6 100644
--- a/src/journal/journald-native.c
+++ b/src/journal/journald-native.c
@@ -75,9 +75,7 @@ static bool allow_object_pid(struct ucred *ucred) {
void server_process_native_message(
Server *s,
const void *buffer, size_t buffer_size,
-struct ucred *ucred,
-struct timeval *tv,
-const char *label, size_t label_len) {
+struct procinfo *procinfo) {
struct iovec *iovec = NULL;
unsigned n = 0, j, tn = (unsigned) -1;
@@ -87,12 +85,20 @@ void server_process_native_message(
char *identifier = NULL, *message = NULL;
pid_t object_pid = 0;
+struct ucred *ucred = NULL;
+struct timeval *tv = NULL;
+
assert(s);
assert(buffer || buffer_size == 0);
p = buffer;
remaining = buffer_size;
+if (procinfo) {
+ucred = procinfo-ucred;
+tv = procinfo-tv;
+}
+
while (remaining 0) {
const char *e, *q;
@@ -106,7 +112,7 @@ void server_process_native_message(
if (e == p) {
/* Entry separator */
-server_dispatch_message(s, iovec, n, m, ucred, tv,
label, label_len, NULL, priority, object_pid);
+server_dispatch_message(s, iovec, n, m, procinfo,
NULL, priority, object_pid);
n = 0;
priority = LOG_INFO;
@@ -266,7 +272,7 @@ void server_process_native_message(
server_forward_wall(s, priority, identifier, message,
ucred);
}
-server_dispatch_message(s, iovec, n, m, ucred, tv, label, label_len,
NULL, priority, object_pid);
+server_dispatch_message(s, iovec, n, m, procinfo, NULL, priority,
object_pid);
finish:
for (j = 0; j n; j++) {
@@ -286,9 +292,7 @@ finish:
void server_process_native_file(
Server *s,
int fd,
-struct ucred *ucred,
-struct timeval *tv,
-const char *label, size_t label_len) {
+struct procinfo *procinfo) {
struct stat st;
_cleanup_free_ void *p = NULL;
@@ -298,7 +302,7 @@ void server_process_native_file(
assert(s);
assert(fd = 0);
-if (!ucred || ucred-uid != 0) {
+if (!procinfo || !procinfo-ucred || procinfo-ucred-uid != 0) {
_cleanup_free_ char *sl = NULL, *k = NULL;
const char *e;
@@ -362,7 +366,7 @@ void server_process_native_file(
if (n 0)
log_error(Failed to read file, ignoring: %s, strerror(-n));
else if (n 0)
-server_process_native_message(s, p, n, ucred, tv, label,
label_len);
+server_process_native_message(s, p, n, procinfo);
}
int server_open_native_socket(Server*s) {
diff --git a/src/journal/journald-native.h b/src/journal/journald-native.h
index bf02fee..858a3d8 100644
--- a/src/journal/journald-native.h
+++ b/src/journal/journald-native.h
@@ -30,8 +30,8 @@
bool valid_user_field(const char *p, size_t l, bool allow_protected);
-void server_process_native_message(Server *s, const void *buffer, size_t
buffer_size, struct ucred *ucred, struct timeval *tv, const char *label, size_t
label_len);
+void
Re: [systemd-devel] [PATCH 1/2] man: Document server sockets in use by journald
On Wed, May 28, 2014 at 10:30:56PM +0200, Lubomir Rintel wrote: --- man/systemd-journald.service.xml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml index f0ce7aa..715 100644 --- a/man/systemd-journald.service.xml +++ b/man/systemd-journald.service.xml @@ -86,6 +86,17 @@ filenamesystemd-journald/filename will then store the data./para +paraJournal listens on +filename/run/systemd/journal/stdout/filename socket of +constantSOCK_STREAM/constant type, and +filename/run/systemd/journal/socket/filename and +filename/dev/log/filename sockets of +constantSOCK_DGRAM/constant type in constantAF_UNIX/constant +family that handle traffic from filenamesystemd-cat/filename, +native clients and syslog local clients respectively. It either +obtains the the handles from systemd via activation socket-passing There is the twice in a row. +interface, or opens them itself./para + journald also always tries to open /dev/kmsg maybe you might wanna mention that as well while at it. parafilenamesystemd-journald/filename will forward all received log messages to the constantAF_UNIX/constant constantSOCK_DGRAM/constant socket -- 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] journald: collect process data from socket data
On Fri, May 30, 2014 at 12:45:21PM +0200, Piotr Wilczek wrote:
This patch adds posibility for journal to get process data from
socket data (if available) instead of from procfs.
Additionally a new procinfo structure is added to store all process
data in single place. This data include creditentials and status.
To enable this functionality, SO_PASSPROC socket option must be set.
This option is introduced in:
http://lwn.net/Articles/600564/
With this patch journald cpu usage is decresed by about 20%
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
---
Thanks for moving this forward! I hope your attempt will go through David's
review.
I know that flag was suggested by Kay, but isn't there a nicer way how to expose
this to userspace given that in man 7 unix is written following:
For historical reasons these socket options are specified with a
SOL_SOCKET type even though they are AF_UNIX specific.
AFAIK we had only SO_PASSCRED and your patchset adds one more.
Michal
src/journal/journald-kmsg.c | 2 +-
src/journal/journald-native.c | 24
src/journal/journald-native.h | 4 +-
src/journal/journald-server.c | 131
+-
src/journal/journald-server.h | 17 +-
src/journal/journald-stream.c | 7 ++-
src/journal/journald-syslog.c | 15 +++--
src/journal/journald-syslog.h | 2 +-
8 files changed, 155 insertions(+), 47 deletions(-)
diff --git a/src/journal/journald-kmsg.c b/src/journal/journald-kmsg.c
index 12992e7..0bac0df 100644
--- a/src/journal/journald-kmsg.c
+++ b/src/journal/journald-kmsg.c
@@ -304,7 +304,7 @@ static void dev_kmsg_record(Server *s, char *p, size_t l)
{
if (message)
IOVEC_SET_STRING(iovec[n++], message);
-server_dispatch_message(s, iovec, n, ELEMENTSOF(iovec), NULL, NULL,
NULL, 0, NULL, priority, 0);
+server_dispatch_message(s, iovec, n, ELEMENTSOF(iovec), NULL, NULL,
priority, 0);
finish:
for (j = 0; j z; j++)
diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
index c54f647..b2c44d6 100644
--- a/src/journal/journald-native.c
+++ b/src/journal/journald-native.c
@@ -75,9 +75,7 @@ static bool allow_object_pid(struct ucred *ucred) {
void server_process_native_message(
Server *s,
const void *buffer, size_t buffer_size,
-struct ucred *ucred,
-struct timeval *tv,
-const char *label, size_t label_len) {
+struct procinfo *procinfo) {
struct iovec *iovec = NULL;
unsigned n = 0, j, tn = (unsigned) -1;
@@ -87,12 +85,20 @@ void server_process_native_message(
char *identifier = NULL, *message = NULL;
pid_t object_pid = 0;
+struct ucred *ucred = NULL;
+struct timeval *tv = NULL;
+
assert(s);
assert(buffer || buffer_size == 0);
p = buffer;
remaining = buffer_size;
+if (procinfo) {
+ucred = procinfo-ucred;
+tv = procinfo-tv;
+}
+
while (remaining 0) {
const char *e, *q;
@@ -106,7 +112,7 @@ void server_process_native_message(
if (e == p) {
/* Entry separator */
-server_dispatch_message(s, iovec, n, m, ucred, tv,
label, label_len, NULL, priority, object_pid);
+server_dispatch_message(s, iovec, n, m, procinfo,
NULL, priority, object_pid);
n = 0;
priority = LOG_INFO;
@@ -266,7 +272,7 @@ void server_process_native_message(
server_forward_wall(s, priority, identifier,
message, ucred);
}
-server_dispatch_message(s, iovec, n, m, ucred, tv, label, label_len,
NULL, priority, object_pid);
+server_dispatch_message(s, iovec, n, m, procinfo, NULL, priority,
object_pid);
finish:
for (j = 0; j n; j++) {
@@ -286,9 +292,7 @@ finish:
void server_process_native_file(
Server *s,
int fd,
-struct ucred *ucred,
-struct timeval *tv,
-const char *label, size_t label_len) {
+struct procinfo *procinfo) {
struct stat st;
_cleanup_free_ void *p = NULL;
@@ -298,7 +302,7 @@ void server_process_native_file(
assert(s);
assert(fd = 0);
-if (!ucred || ucred-uid != 0) {
+if (!procinfo || !procinfo-ucred || procinfo-ucred-uid != 0) {
_cleanup_free_ char *sl = NULL, *k = NULL;
const char *e;
@@ -362,7 +366,7 @@ void server_process_native_file(
if (n 0)
log_error(Failed to read file, ignoring: %s, strerror(-n));
else if (n 0)
-
[systemd-devel] [PATCH v3 0/2] Move initscript parsing to a generator
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com Move initscript parsing to a generator Compared to the previous version this one includes a fix for initscripts that have no start priority. I have also updated the commit messages. The patches have a few warts that I consider irrelevant but am willing to fix if there is interest. The following now unused sysv-specific info are dropped from service dump: * SysV Init Script has LSB Header: (yes/no) * SysVEnabled: (yes/no) * SysVRunLevels: (levels) Note that this drops reading of chkconfig entirely. It also drops reading runlevels from the LSB headers. The runlevels were only used to check for runlevels outside of the normal 1-5 range and then add special dependencies and settings. Special runlevels were dropped in the past so it seemed to be unused code. The generator does not know about non-generated units with a value set with SysVStartPriority=. These are therefor not taken into account when converting start priority to before/after. After the special runlevels were dropped I don't see how this option adds any value. Thomas Hindoe Paaboel Andersen (2): Move handling of sysv initscripts to a generator Remove sysv parser from service.c .gitignore | 1 + Makefile.am | 10 + src/core/service.c | 984 +--- src/core/service.h | 5 - src/sysv-generator/Makefile | 1 + src/sysv-generator/sysv-generator.c | 899 6 files changed, 921 insertions(+), 979 deletions(-) create mode 100644 src/sysv-generator/Makefile create mode 100644 src/sysv-generator/sysv-generator.c -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 2/2] Remove sysv parser from service.c
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
Parsing sysv files was moved to the sysv-generator in the previous commit.
This patch removes the sysv parsing from serivce.c.
To avoid introducing an extra compat option in .service fies for identifying
sysv services we instead add a check if the SourcePath is a path to sysvinit.
Note that this patch drops the following now unused sysv-specific info
from service dump:
SysV Init Script has LSB Header: (yes/no)
SysVEnabled: (yes/no)
SysVRunLevels: (levels)
---
src/core/service.c | 984 +
src/core/service.h | 5 -
2 files changed, 10 insertions(+), 979 deletions(-)
diff --git a/src/core/service.c b/src/core/service.c
index 70e7635..836ca43 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -49,41 +49,6 @@
#include bus-error.h
#include bus-util.h
-#ifdef HAVE_SYSV_COMPAT
-
-#define DEFAULT_SYSV_TIMEOUT_USEC (5*USEC_PER_MINUTE)
-
-typedef enum RunlevelType {
-RUNLEVEL_UP,
-RUNLEVEL_DOWN
-} RunlevelType;
-
-static const struct {
-const char *path;
-const char *target;
-const RunlevelType type;
-} rcnd_table[] = {
-/* Standard SysV runlevels for start-up */
-{ rc1.d, SPECIAL_RESCUE_TARGET,RUNLEVEL_UP },
-{ rc2.d, SPECIAL_RUNLEVEL2_TARGET, RUNLEVEL_UP },
-{ rc3.d, SPECIAL_RUNLEVEL3_TARGET, RUNLEVEL_UP },
-{ rc4.d, SPECIAL_RUNLEVEL4_TARGET, RUNLEVEL_UP },
-{ rc5.d, SPECIAL_RUNLEVEL5_TARGET, RUNLEVEL_UP },
-
-/* Standard SysV runlevels for shutdown */
-{ rc0.d, SPECIAL_POWEROFF_TARGET, RUNLEVEL_DOWN },
-{ rc6.d, SPECIAL_REBOOT_TARGET,RUNLEVEL_DOWN }
-
-/* Note that the order here matters, as we read the
- directories in this order, and we want to make sure that
- sysv_start_priority is known when we first load the
- unit. And that value we only know from S links. Hence
- UP must be read before DOWN */
-};
-
-#define RUNLEVELS_UP 12345
-#endif
-
static const UnitActiveState state_translation_table[_SERVICE_STATE_MAX] = {
[SERVICE_DEAD] = UNIT_INACTIVE,
[SERVICE_START_PRE] = UNIT_ACTIVATING,
@@ -138,11 +103,6 @@ static void service_init(Unit *u) {
s-timeout_stop_usec = u-manager-default_timeout_stop_usec;
s-restart_usec = u-manager-default_restart_usec;
s-type = _SERVICE_TYPE_INVALID;
-
-#ifdef HAVE_SYSV_COMPAT
-s-sysv_start_priority = -1;
-s-sysv_start_priority_from_rcnd = -1;
-#endif
s-socket_fd = -1;
s-guess_main_pid = true;
@@ -295,11 +255,6 @@ static void service_done(Unit *u) {
free(s-pid_file);
s-pid_file = NULL;
-#ifdef HAVE_SYSV_COMPAT
-free(s-sysv_runlevels);
-s-sysv_runlevels = NULL;
-#endif
-
free(s-status_text);
s-status_text = NULL;
@@ -364,734 +319,6 @@ static int service_arm_timer(Service *s, usec_t usec) {
service_dispatch_timer, s);
}
-#ifdef HAVE_SYSV_COMPAT
-static char *sysv_translate_name(const char *name) {
-char *r;
-
-r = new(char, strlen(name) + strlen(.service) + 1);
-if (!r)
-return NULL;
-
-if (endswith(name, .sh))
-/* Drop .sh suffix */
-strcpy(stpcpy(r, name) - 3, .service);
-else
-/* Normal init script name */
-strcpy(stpcpy(r, name), .service);
-
-return r;
-}
-
-static int sysv_translate_facility(const char *name, const char *filename,
char **_r) {
-
-/* We silently ignore the $ prefix here. According to the LSB
- * spec it simply indicates whether something is a
- * standardized name or a distribution-specific one. Since we
- * just follow what already exists and do not introduce new
- * uses or names we don't care who introduced a new name. */
-
-static const char * const table[] = {
-/* LSB defined facilities */
-local_fs, NULL,
-network, SPECIAL_NETWORK_ONLINE_TARGET,
-named,SPECIAL_NSS_LOOKUP_TARGET,
-portmap, SPECIAL_RPCBIND_TARGET,
-remote_fs,SPECIAL_REMOTE_FS_TARGET,
-syslog, NULL,
-time, SPECIAL_TIME_SYNC_TARGET,
-};
-
-unsigned i;
-char *r;
-const char *n;
-
-assert(name);
-assert(_r);
-
-n = *name == '$' ? name + 1 : name;
-
-for (i = 0; i ELEMENTSOF(table); i += 2) {
-
-if (!streq(table[i], n))
-continue;
-
-if (!table[i+1])
-return 0;
-
-r = strdup(table[i+1]);
-if (!r)
-return log_oom();
-
-goto finish;
[systemd-devel] [PATCH v3 1/2] Move handling of sysv initscripts to a generator
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
Reuses logic from service.c and the rc-local generator.
Note that this drops reading of chkconfig entirely. It also drops reading
runlevels from the LSB headers. The runlevels were only used to check for
runlevels outside of the normal 1-5 range and then add special dependencies
and settings. Special runlevels were dropped in the past so it seemed to be
unused code.
The generator does not know about non-generated units with a value set with
SysVStartPriority=. These are therefor not taken into account when converting
start priority to before/after.
---
.gitignore | 1 +
Makefile.am | 10 +
src/sysv-generator/Makefile | 1 +
src/sysv-generator/sysv-generator.c | 899
4 files changed, 911 insertions(+)
create mode 100644 src/sysv-generator/Makefile
create mode 100644 src/sysv-generator/sysv-generator.c
diff --git a/.gitignore b/.gitignore
index 908c563..061b4af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -101,6 +101,7 @@
/systemd-socket-proxyd
/systemd-sysctl
/systemd-system-update-generator
+/systemd-sysv-generator
/systemd-timedated
/systemd-timesyncd
/systemd-tmpfiles
diff --git a/Makefile.am b/Makefile.am
index f66ef42..69d5a84 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -549,6 +549,7 @@ nodist_systemunit_DATA += \
units/halt-local.service
systemgenerator_PROGRAMS += \
+ systemd-sysv-generator \
systemd-rc-local-generator
endif
@@ -1915,6 +1916,15 @@ UNINSTALL_EXEC_HOOKS += dbus1-generator-uninstall-hook
endif
#
--
+systemd_sysv_generator_SOURCES = \
+ src/sysv-generator/sysv-generator.c
+
+systemd_sysv_generator_LDADD = \
+ libsystemd-core.la \
+ libsystemd-label.la \
+ libsystemd-shared.la
+
+#
--
systemd_rc_local_generator_SOURCES = \
src/rc-local-generator/rc-local-generator.c
diff --git a/src/sysv-generator/Makefile b/src/sysv-generator/Makefile
new file mode 100644
index 000..530e5e9
--- /dev/null
+++ b/src/sysv-generator/Makefile
@@ -0,0 +1 @@
+../Makefile
diff --git a/src/sysv-generator/sysv-generator.c
b/src/sysv-generator/sysv-generator.c
new file mode 100644
index 000..565fcaa
--- /dev/null
+++ b/src/sysv-generator/sysv-generator.c
@@ -0,0 +1,899 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright 2014 Thomas H.P. Andersen
+ Copyright 2010 Lennart Poettering
+ Copyright 2011 Michal Schmidt
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include errno.h
+#include stdio.h
+#include unistd.h
+
+#include util.h
+#include mkdir.h
+#include strv.h
+#include path-util.h
+#include path-lookup.h
+#include log.h
+#include strv.h
+#include unit.h
+#include unit-name.h
+#include special.h
+#include exit-status.h
+#include def.h
+#include env-util.h
+#include fileio.h
+#include hashmap.h
+
+typedef enum RunlevelType {
+RUNLEVEL_UP,
+RUNLEVEL_DOWN
+} RunlevelType;
+
+static const struct {
+const char *path;
+const char *target;
+const RunlevelType type;
+} rcnd_table[] = {
+/* Standard SysV runlevels for start-up */
+{ rc1.d, SPECIAL_RESCUE_TARGET,RUNLEVEL_UP },
+{ rc2.d, SPECIAL_RUNLEVEL2_TARGET, RUNLEVEL_UP },
+{ rc3.d, SPECIAL_RUNLEVEL3_TARGET, RUNLEVEL_UP },
+{ rc4.d, SPECIAL_RUNLEVEL4_TARGET, RUNLEVEL_UP },
+{ rc5.d, SPECIAL_RUNLEVEL5_TARGET, RUNLEVEL_UP },
+
+/* Standard SysV runlevels for shutdown */
+{ rc0.d, SPECIAL_POWEROFF_TARGET, RUNLEVEL_DOWN },
+{ rc6.d, SPECIAL_REBOOT_TARGET,RUNLEVEL_DOWN }
+
+/* Note that the order here matters, as we read the
+ directories in this order, and we want to make sure that
+ sysv_start_priority is known when we first load the
+ unit. And that value we only know from S links. Hence
+ UP must be read before DOWN */
+};
+
+typedef struct SysvStub {
+char *name;
+char *path;
+char *description;
+int sysv_start_priority;
+char *pid_file;
+char **before;
+char **after;
+
Re: [systemd-devel] [PATCH] units: use KillMode=mixed for systemd-nspawn@.service
On Thu, May 29, 2014 at 01:17:25AM +1000, Jonathan Liu wrote: This causes the container to shut down cleanly when the service is stopped. --- units/systemd-nsp...@.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/units/systemd-nsp...@.service.in b/units/systemd-nsp...@.service.in index ff36e90..e373628 100644 --- a/units/systemd-nsp...@.service.in +++ b/units/systemd-nsp...@.service.in @@ -11,6 +11,7 @@ Documentation=man:systemd-nspawn(1) [Service] ExecStart=@bindir@/systemd-nspawn --quiet --keep-unit --boot --link-journal=guest --directory=/var/lib/container/%i +KillMode=mixed Type=notify Took me a while to test properly, but indeed, this fixes container shutdown. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
I'd really hope we could avoid setting broadcast everywhere, as that
seems very wasteful...
I agree with you, broadcasting everywhere it's clearly not convenient.
It seems to me the ideal path to move forward looks like this:
1. Use platform specific raw sockets for the first attempt of getting a
DHCPOFFER, through unicast and without ARP. Just like ISC's does
https://kb.isc.org/article/AA-00379/0/How-DHCP-uses-raw-sockets.html.
2. If *1* doesn't work, fall back to normal BSD sockets setting the
broadcast flag on. This is done by ISC's impl too, as I showed in my
previous email. See https://cloudup.com/cAneyImU2H2 and
https://gist.github.com/c4milo/017a50a6f5d329887707
3. Use Tom's patch for qeth devices setting
/sys/class/net/%s/device/layer2 to 0 which seems to happen
https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8
but it will be nice to confirm.
4. Provide a configuration parameter for administrators to set the
broadcast flag manually.
In essence, Patrik's proposal is the same as 1 and 2, just a different
implementation.
+ if (link-udev_device) {
+ const char *l2;
+
+ l2 = udev_device_get_sysattr_value(link-udev_device, layer2);
+ if (l2) {
+ unsigned layer2;
+
+ r = safe_atou(l2, layer2);
+ if (r 0)
+ return r;
+
+ if (!layer2) {
+ r = sd_dhcp_client_request_
broadcast(link-dhcp_client);
+ if (r 0)
+ return r;
+ }
Am I now missing something if I can't find the
file /sys/class/net/device/device/layer2 for a regular networking
interface? The above enables broadcast only for virtual interfaces,
right?
Patrik, based on what Tom says, I think the above patch will only cover
qeth devices setting /sys/class/net/%s/device/layer2 in 0 which seems to
happen in some cases:
https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8
The issue that brought me here is consistently happening in VMware virtual
machines using bridged networking: https://github.com/coreos/bugs/issues/12
Best,
Camilo
On Fri, May 30, 2014 at 4:06 AM, Tom Gundersen t...@jklm.no wrote:
On Fri, May 30, 2014 at 3:24 AM, Camilo Aguilar
camilo.agui...@gmail.com wrote:
Hi Tom, the patch did not work because there is no layer2 file. Would it
be
safe to assume that no file is the same as the file having 0? This is
out of
my reach unfortunately, but I will be happy to read whatever link you
throw
at me.
I don't think that would work, as only the qeth driver actually
exposes the layer2 file (and to the best of my knowledge the other
upstream drivers support unicast). If other drivers also can't do
unicast, then they need to expose this information to us somehow, I'm
afraid that I don't know anything about the VMWare driver, but
hopefully we can find a way to get this info out of that driver too
(would of course be nice if everyone used the same interface...).
Also, to better clarify how ISC dhcp-4.3.0 works. It seems it uses raw
sockets as a first attempt (layer2 unicast) and falls back to normal BSD
sockets which will always set the broadcast flag on:
https://cloudup.com/cAneyImU2H2 and
https://gist.github.com/c4milo/017a50a6f5d329887707
I'd really hope we could avoid setting broadcast everywhere, as that
seems very wasteful...
Cheers,
Tom
--
*Camilo Aguilar*
Software Engineer
http://github.com/c4milo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 12:50:50PM +0300, Samuli Suominen wrote: On 30/05/14 09:17, Cristian Rodríguez wrote: El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... You are right, this fhandle business is new, but we have 208 for kernels with no CONFIG_FHANDLE, and 212/213 for ones without, I have plans on keeping 208 for a long time in tree (it's on my TODO list to apply the patch that adds CONFIG_FHANDLE to our special kernel sources, but it's not done yet) We have embedded uses for eg. Genesis Efika MX (arm neon processor) with special kernel patches 2.6.32.* series, just to name one I personally use, and I know we have more of these uses, all ARM related Then stick with those old systemd/udev versions for those kernels, nothings wrong with that. But seriously, if at all possible, please keep the firmware thing for like this year in the code, it would be greately appericiated Why would 6 months make any difference for removing it then vs. now? greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30/05/14 17:13, Greg KH wrote: On Fri, May 30, 2014 at 12:50:50PM +0300, Samuli Suominen wrote: On 30/05/14 09:17, Cristian Rodríguez wrote: El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... You are right, this fhandle business is new, but we have 208 for kernels with no CONFIG_FHANDLE, and 212/213 for ones without, I have plans on keeping 208 for a long time in tree (it's on my TODO list to apply the patch that adds CONFIG_FHANDLE to our special kernel sources, but it's not done yet) We have embedded uses for eg. Genesis Efika MX (arm neon processor) with special kernel patches 2.6.32.* series, just to name one I personally use, and I know we have more of these uses, all ARM related Then stick with those old systemd/udev versions for those kernels, nothings wrong with that. Yes there is, it means an extra step for the users to mask newer versions, and burden for maintainers to backtrack patches for bugfixes for old version But seriously, if at all possible, please keep the firmware thing for like this year in the code, it would be greately appericiated Why would 6 months make any difference for removing it then vs. now? Because new kernel patchsets are being written, some are semi-ready in various version controls, some are not, giving time for upstreams to migrate is usually good idea, expecting everyone is ready when you say jump is not realistic If it's really not a big problem to maintain the firmware loader for some time longer, please just do that :/ - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Fri, May 30, 2014 at 06:05:19PM +0300, Samuli Suominen wrote: On 30/05/14 17:13, Greg KH wrote: On Fri, May 30, 2014 at 12:50:50PM +0300, Samuli Suominen wrote: On 30/05/14 09:17, Cristian Rodríguez wrote: El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió: On 30/05/14 04:55, Greg KH wrote: On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. I think this patch is a bad idea - it makes things harder for people who, for whatever reason, good or bad, run older kernels. At the same time, our maintenance burden is pretty much zero. What kernel version are you thinking still needs this, that would ever want to have a new version of systemd on it? We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch would be very harmful to us (Gentoo) Really ? the minimum requirements are: REQUIREMENTS: Linux kernel = 3.0 Linux kernel = 3.3 for loop device partition support features with nspawn Linux kernel = 3.8 for Smack support Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ... You are right, this fhandle business is new, but we have 208 for kernels with no CONFIG_FHANDLE, and 212/213 for ones without, I have plans on keeping 208 for a long time in tree (it's on my TODO list to apply the patch that adds CONFIG_FHANDLE to our special kernel sources, but it's not done yet) We have embedded uses for eg. Genesis Efika MX (arm neon processor) with special kernel patches 2.6.32.* series, just to name one I personally use, and I know we have more of these uses, all ARM related Then stick with those old systemd/udev versions for those kernels, nothings wrong with that. Yes there is, it means an extra step for the users to mask newer versions, and burden for maintainers to backtrack patches for bugfixes for old version That burden is on you in the first place for agreeing to keep supporting such old and obsolete kernels. Not on others who made no such agreement or decision. But seriously, if at all possible, please keep the firmware thing for like this year in the code, it would be greately appericiated Why would 6 months make any difference for removing it then vs. now? Because new kernel patchsets are being written, some are semi-ready in various version controls, some are not, giving time for upstreams to migrate is usually good idea, expecting everyone is ready when you say jump is not realistic The kernel said jump a long time ago, why didn't you change then? If it's really not a big problem to maintain the firmware loader for some time longer, please just do that :/ Again, why should we care about older distros who rely on older kernels? The burden of keeping code running on those older kernels is up to the developers who made the decision to keep running them, not to upstream projects who know better. As you say, the patch is simple for you to keep in your tree, if you want to keep the feature around. That way you can keep running old kernels for a decade if you decide to. But honestly, it makes no sense anymore to keep this in the repo at all. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] localed: consider an unset model as a wildcard
---
src/locale/localed.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/locale/localed.c b/src/locale/localed.c
index e3061c8..358f6c2 100644
--- a/src/locale/localed.c
+++ b/src/locale/localed.c
@@ -712,15 +712,16 @@ static int find_legacy_keymap(Context *c, char
**new_keymap) {
}
}
-if (matching 0
-streq_ptr(c-x11_model, a[2])) {
-matching++;
-
-if (streq_ptr(c-x11_variant, a[3])) {
+if (matching 0) {
+if (isempty(c-x11_model) || streq_ptr(c-x11_model,
a[2])) {
matching++;
-if (streq_ptr(c-x11_options, a[4]))
+if (streq_ptr(c-x11_variant, a[3])) {
matching++;
+
+if (streq_ptr(c-x11_options, a[4]))
+matching++;
+}
}
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
On 30 May 2014 10:25, Patrik Flykt patrik.fl...@linux.intel.com wrote:
On Thu, 2014-05-29 at 18:18 +0100, Tom Gundersen wrote:
+ if (link-udev_device) {
+ const char *l2;
+
+ l2 = udev_device_get_sysattr_value(link-udev_device, layer2);
+ if (l2) {
+ unsigned layer2;
+
+ r = safe_atou(l2, layer2);
+ if (r 0)
+ return r;
+
+ if (!layer2) {
+ r =
sd_dhcp_client_request_broadcast(link-dhcp_client);
+ if (r 0)
+ return r;
+ }
Am I now missing something if I can't find the
file /sys/class/net/device/device/layer2 for a regular networking
interface? The above enables broadcast only for virtual interfaces,
right?
That's correct. My hope was that the interfaces that require broadcast
would expose that somehow. It appears that's not the case, so a scheme like
yours sounds more robust.
I'm wondering if the criterion should be to request broadcast if and only
if we have not configured an IP address (I.e. only in discovering,
requesting and init-reboot), as that seems to be the problem, or did I get
that wrong?
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
On 30 May 2014 10:12, Patrik Flykt patrik.fl...@linux.intel.com wrote: On Thu, 2014-05-29 at 00:03 +0100, Tom Gundersen wrote: On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar camilo.agui...@gmail.com wrote: In systems running on hypervisors this flag needs to be set ON, so offers can reach the virtual machines. For more information please refer to this thread in CoreOS: https://github.com/coreos/bugs/issues/12 Signed-off-by: Camilo Aguilar camilo.agui...@gmail.com --- src/libsystemd-network/sd-dhcp-client.c | 9 + 1 file changed, 9 insertions(+) diff --git a/src/libsystemd-network/sd-dhcp-client.c b/src/libsystemd-network/sd-dhcp-client.c index 0300a6b..8f54906 100644 --- a/src/libsystemd-network/sd-dhcp-client.c +++ b/src/libsystemd-network/sd-dhcp-client.c @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client *client, DHCPPacket **ret, refuse to issue an DHCP lease if 'secs' is set to zero */ packet-dhcp.secs = htobe16(client-secs); +/* RFC2132 section 4.1 + A client that cannot receive unicast IP datagrams until its protocol + software has been configured with an IP address SHOULD set the + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or + DHCPREQUEST messages that client sends. The BROADCAST bit will + provide a hint to the DHCP server and BOOTP relay agent to broadcast + any messages to the client on the client's subnet. */ +packet-dhcp.flags = htobe16(0x8000); Hm, most clients can and should use unicast, so we should definitely not request broadcast unconditionally. If there really is a situation where we need broadcast, we should detect that and only request broadcast in this case. Does that make sense? Actually, I have had recent reports from users that there seems to exist a category of networking devices Do you have any more info on this by any chance? Any way we may classify these devices in a robust way? which discard DHCPv4 messages unless the messages are sent by broadcast. The users say that forcing the DHCPv4 clients to use broadcast fixes the problem. I recently added a patch to ConnMan that always requests broadcast replies when it is sending broadcast itself. That means broadcast DHCPDiscover - DHCPOffer messages as well as DHCPRequest - DHCPAck/Nak messages in Requesting and Rebinding states. Unicast is used for most of the normal message sending in the Renewing state. This way not every message is broadcast and if unicast messages disappear, there is always Rebinding that gets through before lease expiry. Should we do the same thing in networkd? Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. Ok, it turns out there is still one kernel driver that requires this to work properly, so we can't delete it just yet :( Now, if the people clamoring for us keeping this code would have done their homework and figured this out, that would have been wonderful, and saved everyone a bunch of time. bah, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev-builtin-keyboard: do tell on which device EVIOCSKEYCODE failed.
I am getting Error calling EVIOCSKEYCODE (scan code 0xc022d, key code 418): Invalid argument, the error message does not tell on which specific device the problem is, add that info. --- src/udev/udev-builtin-keyboard.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/udev/udev-builtin-keyboard.c b/src/udev/udev-builtin-keyboard.c index 614e44e..9b66bfd 100644 --- a/src/udev/udev-builtin-keyboard.c +++ b/src/udev/udev-builtin-keyboard.c @@ -143,7 +143,7 @@ static int builtin_keyboard(struct udev_device *dev, int argc, char *argv[], boo log_debug(keyboard: mapping scan code %d (0x%x) to key code %d (0x%x), map[i].scan, map[i].scan, map[i].key, map[i].key); if (ioctl(fd, EVIOCSKEYCODE, map[i]) 0) -log_error(Error calling EVIOCSKEYCODE (scan code 0x%x, key code %d): %m, map[i].scan, map[i].key); +log_error(Error calling EVIOCSKEYCODE on device node '%s' (scan code 0x%x, key code %d): %m, node, map[i].scan, map[i].key); } /* install list of force-release codes */ -- 1.8.4.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
El 30/05/14 13:08, Greg KH escribió: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. Ok, it turns out there is still one kernel driver that requires this to work properly, so we can't delete it just yet :( Now, if the people clamoring for us keeping this code would have done their homework and figured this out, that would have been wonderful, and saved everyone a bunch of time. Maybe I am not understanding something well. but the driver appears to require the *kernel* side of this functionality. https://www.kernel.org/doc/Documentation/dell_rbu.txt Because I am pretty sure udev is not in the business of BIOS updates.. -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 30 May 2014 18:25, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 30/05/14 13:08, Greg KH escribió: On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote: As discussed ad-nauseum previously, it is the kernel's task to load firmware, not udev's. Ok, it turns out there is still one kernel driver that requires this to work properly, so we can't delete it just yet :( Now, if the people clamoring for us keeping this code would have done their homework and figured this out, that would have been wonderful, and saved everyone a bunch of time. Maybe I am not understanding something well. but the driver appears to require the *kernel* side of this functionality. https://www.kernel.org/doc/Documentation/dell_rbu.txt Because I am pretty sure udev is not in the business of BIOS updates.. True, but until that is fixed on the kernel side the support is still required on the udev side for things to work in all cases (sorry for not pointing this out earlier BTW). I think what some distros have done is to just rip out the Dell bios thing, but I guess that won't fly in the upstream kernel. Refactoring this on the kernel side so the dell stuff is not tied to the regular firmware loader should not be hard from what I can tell... (to be honest the whole thing looks like a pretty bad abuse of the interface). Any takers? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
