[systemd-devel] [PATCH] connection: update conn-flags before kdbus_notify_id_change uses them
Signed-off-by: Radoslaw Pajak r.pa...@samsung.com
---
connection.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/connection.c b/connection.c
index 95f75e1..9982da2 100644
--- a/connection.c
+++ b/connection.c
@@ -1884,6 +1884,9 @@ int kdbus_conn_new(struct kdbus_ep *ep,
BUILD_BUG_ON(sizeof(bus-id128) != sizeof(hello-id128));
memcpy(hello-id128, bus-id128, sizeof(hello-id128));
+ conn-flags = hello-conn_flags;
+ conn-attach_flags = hello-attach_flags;
+
/* notify about the new active connection */
ret = kdbus_notify_id_change(KDBUS_ITEM_ID_ADD, conn-id, conn-flags,
notify_list);
@@ -1891,9 +1894,6 @@ int kdbus_conn_new(struct kdbus_ep *ep,
goto exit_unref_ep;
kdbus_conn_kmsg_list_send(conn-ep, notify_list);
- conn-flags = hello-conn_flags;
- conn-attach_flags = hello-attach_flags;
-
if (activator_name) {
u64 flags = KDBUS_NAME_ACTIVATOR;
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] linux container started with systemd-nspawn
Hmm, where's the difference if I may ask? With David's commit I see no empty lines in the generated output? Lennart -- Lennart Poettering, Red Hat So fine if it works for you In my case, systemd didn't built with dave's pacth because of a few blank lined left in the generated .gperf file. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] connection: update conn-flags before kdbus_notify_id_change uses them
Signed-off-by: Radoslaw Pajak r.pa...@samsung.com
---
connection.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/connection.c b/connection.c
index 95f75e1..9982da2 100644
--- a/connection.c
+++ b/connection.c
@@ -1884,6 +1884,9 @@ int kdbus_conn_new(struct kdbus_ep *ep,
BUILD_BUG_ON(sizeof(bus-id128) != sizeof(hello-id128));
memcpy(hello-id128, bus-id128, sizeof(hello-id128));
+ conn-flags = hello-conn_flags;
+ conn-attach_flags = hello-attach_flags;
+
/* notify about the new active connection */
ret = kdbus_notify_id_change(KDBUS_ITEM_ID_ADD, conn-id,
conn-flags,
notify_list);
@@ -1891,9 +1894,6 @@ int kdbus_conn_new(struct kdbus_ep *ep,
goto exit_unref_ep;
kdbus_conn_kmsg_list_send(conn-ep, notify_list);
- conn-flags = hello-conn_flags;
- conn-attach_flags = hello-attach_flags;
-
if (activator_name) {
u64 flags = KDBUS_NAME_ACTIVATOR;
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with systemd-coredump
Am 17.02.2014 21:27, schrieb Manuel Reimer: As soon as a bigger coredump (about 500 MB) is to be stored, the whole system slows down significantly. Seems like storing such big amounts of data takes pretty long and is a very CPU hungry process... I completely agree. Since the kernel ignores the maximum coredump size when core_pattern is used, a significant amount of time passes whenever a larger process crashes, with no benefit (since the dump never gets saved anywhere). This is extremely annoying if processes with sizes in the tens or hundreds of gigabytes crash, which sadly happened to me quite a few times recently. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] needed steps to get rebootless upgrade
2014-02-18 0:29 GMT+04:00 H. Peter Anvin h...@zytor.com: Well, kexec passes an initramfs like any other boot. Thanks. If that possible to not load initrd via kexec, but use already unpacked image in the memory? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On 02/18/2014 05:03 AM, Zbigniew Jędrzejewski-Szmek wrote: A related question is wheter Fedora should get this release in rawhide: I think yes, but with --disable-kdbus --enable-compat-libs. It's nice thathttps://bugzilla.redhat.com/show_bug.cgi?id=1065572 got fixed just in time. Rawhide is the place for breakage and we want to catch any related bugs sooner rather then later so why disable kdbus? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with systemd-coredump
On Tue, Feb 18, 2014 at 11:05 AM, Thomas Bächler tho...@archlinux.org wrote: Am 17.02.2014 21:27, schrieb Manuel Reimer: As soon as a bigger coredump (about 500 MB) is to be stored, the whole system slows down significantly. Seems like storing such big amounts of data takes pretty long and is a very CPU hungry process... I completely agree. Since the kernel ignores the maximum coredump size when core_pattern is used, a significant amount of time passes whenever a larger process crashes, with no benefit (since the dump never gets saved anywhere). This is extremely annoying if processes with sizes in the tens or hundreds of gigabytes crash, which sadly happened to me quite a few times recently. It's an incomplete and rather fragile solution the way it works today. We cannot really *malloc()* the memory for a core dump, it's *pipe* from the kernel for a reason. It can be as large as the available RAM, that's why it's limited to the current maximum size, and therefore also limited in its usefulness. It really always needs to be extracted to be a minidump to store away. There are no other sensible options when things should end up in the journal. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On Tue, Feb 18, 2014 at 10:57:23AM +, Jóhann B. Guðmundsson wrote: On 02/18/2014 05:03 AM, Zbigniew Jędrzejewski-Szmek wrote: A related question is wheter Fedora should get this release in rawhide: I think yes, but with --disable-kdbus --enable-compat-libs. It's nice thathttps://bugzilla.redhat.com/show_bug.cgi?id=1065572 got fixed just in time. Rawhide is the place for breakage and we want to catch any related bugs sooner rather then later so why disable kdbus? Because it is not in upstream kernel, therefore not in rawhide. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On Tue, Feb 18, 2014 at 6:03 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Feb 18, 2014 at 03:26:35AM +0100, Lennart Poettering wrote: It's release time again! It has been more than 4 months now since the last release. That's kinda emberassing, since we actually intended to go for a 2-3 week cycle... The big dbus transition took some time however. Aynway, I just finished a review of the git history, marked backportable fixes, and put together the NEWS. Kay, Zbigniew, Tom, David, Patrik, anything left to fix before I roll a release? I'd like to roll the release tomorrow (tuesday) or wednesday. Please have a closer look and test! Hi, please give it a week to mature. This is a great release and a lot of people are waiting for it. But there are certainly small bugs left... and a week of testing and bug-fix-only commits would be beneficial, imho. There will be more releases coming soon after release, I expect. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On Tue, Feb 18, 2014 at 11:57 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 02/18/2014 05:03 AM, Zbigniew Jędrzejewski-Szmek wrote: A related question is wheter Fedora should get this release in rawhide: I think yes, but with --disable-kdbus --enable-compat-libs. It's nice thathttps://bugzilla.redhat.com/show_bug.cgi?id=1065572 got fixed just in time. Rawhide is the place for breakage and we want to catch any related bugs sooner rather then later so why disable kdbus? It is completely insecure and work-in-progress, the API is not finished, the kernel side not generally available. Kdbus in systemd is useless and cannot be tested without the kernel module. We will still change the kernel module API, so any change in a newer systemd, or the kernel, will render the machine using kdbus unbootable. It is really no stuff a distribution should ship at this moment. make install for systemd is as easy to do as the make install of the kernel module, for people who want to play with kdbus. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On 02/18/2014 03:26 AM, Lennart Poettering wrote: It's release time again! It has been more than 4 months now since the last release. That's kinda emberassing, since we actually intended to go for a 2-3 week cycle... The big dbus transition took some time however. Aynway, I just finished a review of the git history, marked backportable fixes, and put together the NEWS. Kay, Zbigniew, Tom, David, Patrik, anything left to fix before I roll a release? I'd like to roll the release tomorrow (tuesday) or wednesday. Please have a closer look and test! Is there a way I can help with testing? I am not a systemd guru, but if there is a (simple) way I could help with testing, I would not mind. I work with openSUSE, but I could install other distributions in a VirtualBox. Met vriendelijke groet, Cecil Westerhof Engineer mobiel +31 - 6 - 25 00 38 81 -- Snow B.V. Unix Specialists De Ooyen 11 4191 PB Geldermalsen http://www.snow.nl tel. +31 - 345 - 65 66 66 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] needed steps to get rebootless upgrade
On 02/18/2014 02:32 AM, Vasiliy Tolstov wrote: 2014-02-18 0:29 GMT+04:00 H. Peter Anvin h...@zytor.com: Well, kexec passes an initramfs like any other boot. Thanks. If that possible to not load initrd via kexec, but use already unpacked image in the memory? Not if it is an (init)ramfs. If it is an actual initrd it can be done, but it is kind of pointless. -hpa ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On Tue, Feb 18, 2014 at 1:20 PM, Jan Janssen medhe...@web.de wrote: the *.link files for networkd completely lack documentation. They are documented in udev(8). Let me know if anything is unclear or lacking. And in general, I would say that networkd could benefit from a more detailed man page before this gets released. Anything in particular you feel is unclear or lacking (I'm going through it now anyway, but more input is always better)? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On Tue, 18.02.14 06:03, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: It's release time again! It has been more than 4 months now since the last release. That's kinda emberassing, since we actually intended to go for a 2-3 week cycle... The big dbus transition took some time however. Aynway, I just finished a review of the git history, marked backportable fixes, and put together the NEWS. Kay, Zbigniew, Tom, David, Patrik, anything left to fix before I roll a release? I'd like to roll the release tomorrow (tuesday) or wednesday. Please have a closer look and test! Hi, please give it a week to mature. This is a great release and a lot of people are waiting for it. But there are certainly small bugs left... and a week of testing and bug-fix-only commits would be beneficial, imho. I think I'd prefer simply doing a release that we declare as one of those people shouldn't base their LTS distros on, and then quickly doing follow-up releases. We should try hard to get much faster with releases again. A related question is wheter Fedora should get this release in rawhide: I think yes, but with --disable-kdbus --enable-compat-libs. It's nice that https://bugzilla.redhat.com/show_bug.cgi?id=1065572 got fixed just in time. Hmm, I wonder if we should just do the work and rebuild all packages that use the old libraries and then disable the compat libs in the RPM. But then again, I am a very lazy person But yeah, it is definitely my intention to upload this to rawhide quickly with --disable-kdbus set. 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] linux container started with systemd-nspawn
On Tue, 18.02.14 09:50, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Hmm, where's the difference if I may ask? With David's commit I see no empty lines in the generated output? Lennart So fine if it works for you In my case, systemd didn't built with dave's pacth because of a few blank lined left in the generated .gperf file. Well, if the current m4 macros don't work correctly on your system we should certainly fix that upstream, that's why I was asking in which way your patch precisely differs from what's currently upstream? Thanks, 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] [HEADS-UP] It's release time!
On Tue, 18.02.14 12:26, Cecil Westerhof (cecil.wester...@snow.nl) wrote: On 02/18/2014 03:26 AM, Lennart Poettering wrote: It's release time again! It has been more than 4 months now since the last release. That's kinda emberassing, since we actually intended to go for a 2-3 week cycle... The big dbus transition took some time however. Aynway, I just finished a review of the git history, marked backportable fixes, and put together the NEWS. Kay, Zbigniew, Tom, David, Patrik, anything left to fix before I roll a release? I'd like to roll the release tomorrow (tuesday) or wednesday. Please have a closer look and test! Is there a way I can help with testing? I am not a systemd guru, but if there is a (simple) way I could help with testing, I would not mind. You can build systemd from the git tree and just install it over your RPM supplied systemd version, but if you do that you really should know what you are doing, and if you are not sure, better step away. Other than that please wait for your distribution to provide RPMs for testing. For example, on Fedora there's Rawhide that provides these usually quickly. 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] [HEADS-UP] It's release time!
On 02/18/2014 02:00 PM, Lennart Poettering wrote: It's release time again! It has been more than 4 months now since the last release. That's kinda emberassing, since we actually intended to go for a 2-3 week cycle... The big dbus transition took some time however. Aynway, I just finished a review of the git history, marked backportable fixes, and put together the NEWS. Kay, Zbigniew, Tom, David, Patrik, anything left to fix before I roll a release? I'd like to roll the release tomorrow (tuesday) or wednesday. Please have a closer look and test! Is there a way I can help with testing? I am not a systemd guru, but if there is a (simple) way I could help with testing, I would not mind. You can build systemd from the git tree and just install it over your RPM supplied systemd version, but if you do that you really should know what you are doing, and if you are not sure, better step away. Then I should step away. But on the other hand, I could just create VM's. If they bomb out: no problem. Met vriendelijke groet, Cecil Westerhof Engineer mobiel +31 - 6 - 25 00 38 81 -- Snow B.V. Unix Specialists De Ooyen 11 4191 PB Geldermalsen http://www.snow.nl tel. +31 - 345 - 65 66 66 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] linux container started with systemd-nspawn
Well, if the current m4 macros don't work correctly on your system we should certainly fix that upstream, that's why I was asking in which way your patch precisely differs from what's currently upstream? Thanks, Lennart I just confused which patch you were talking about. David's one is for sure the same as mine. Dave's one, posted above, was incomplete. Everything is under control now. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Set loaded_policy in smack_setup()
It was 2014-02-14 pią 02:24, when Lennart Poettering wrote: On Thu, 19.12.13 16:58, Łukasz Stelmach (l.stelm...@samsung.com) wrote: With loaded_policy set to true mount_setup() relabels /dev properly. Hmm, is this still relevant? (this == [1]) I am not grokking this patch though, as the only result of this is that label_fix() is called for all device nodes... However, label_fix() only does something on SELinux systems, it has no effect on SMACK, or does it? What am I missing? Ok, it's been some time. Let me rebase and see... Hmm... It appears this one should have been applied to our tree, where we do something smackish[1] in label_fix(), rather than yours. Casey, Do you have any plans to push the commit[1] upstream? Footnotes: [1] http://article.gmane.org/gmane.comp.sysutils.systemd.devel/15596 [2] https://review.tizen.org/git/?p=platform/upstream/systemd.git;a=commitdiff;h=8445e9990936244ccb0a1023baa5abf77f3ae2c4 -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgpHO2jm7EnRY.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] NEWS: fix typos and grammar errors
On Tue, Feb 18, 2014 at 12:28:42AM -0500, Jason St. John wrote: --- This is a resubmit that should apply cleanly on top of Jan Engelhardt's latest patch (commit 4670e9d). Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
Gesendet: Dienstag, 18. Februar 2014 um 13:33 Uhr Von: Tom Gundersen t...@jklm.no An: Jan Janssen medhe...@web.de Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Betreff: Re: [systemd-devel] [HEADS-UP] It's release time! On Tue, Feb 18, 2014 at 1:20 PM, Jan Janssen medhe...@web.de wrote: the *.link files for networkd completely lack documentation. They are documented in udev(8). Let me know if anything is unclear or lacking. Ah, thanks. This really needs a proper mention/link in systemd-networkd manpage or put there instead, the inexpressive udev(7) reference at the end is not enough. When poeple are reading up on networkd, they will not expect this information to be in the udev manpage, even though the implementation of this is (rightfully) located in udev. And in general, I would say that networkd could benefit from a more detailed man page before this gets released. Anything in particular you feel is unclear or lacking (I'm going through it now anyway, but more input is always better)? Nothing in particular. From reading it - and now that I know out about the .link files - I (and others in general) would be able to use it for my purposes right away. I was more thinking on the lines of a condensed down version of your G+ posts on networkd in its manpage. Mainly how it is supposed to work (the big picture), how it interacts with NetworkManager et.al., and also what it currently does not provide/is lacking. And maybe some examples on different set ups, since those are always nice in a manpage to know that you're not doing it wrongly and give you a warm fuzzy feeling :D Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fix SECCOMP_CFLAGS usage
SECCOMP_CFLAGS must be in the global CFLAGS as seccomp.h is included in core/execute.h. when seccomp.h is not in the standard path.(i.e openSUSE has it in /usr/include/pkg/libseccomp/, precisely to catch this kind of bugs) compiling systemd fails. --- Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile.am b/Makefile.am index 79c49e6..18df645 100644 --- a/Makefile.am +++ b/Makefile.am @@ -196,6 +196,7 @@ AM_CPPFLAGS = \ -I $(top_srcdir)/src/libsystemd/sd-bus \ -I $(top_srcdir)/src/libsystemd/sd-event \ -I $(top_srcdir)/src/libsystemd/sd-rtnl \ + $(SECCOMP_CFLAGS) \ $(OUR_CPPFLAGS) AM_CFLAGS = $(OUR_CFLAGS) -- 1.8.4.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/3] Add basic DHCP client test case
Hi, To celebrate the upcoming release, here is a test case that runs the basic client side DHCP Discover-Offer-Request-ACK sequence (patch 03). This test should catch any major breakages with the client implementation. Of course more tests are needed, but let's start with this one. Patch 01 implements some pretty-printing, should one like to have a more verbose output of what's going on, perhaps using a future command line switch or so. Patch 02 factors out the code such that the actual test sequence in patch 03 is easier to implement. It's not the prettiest solution in the world but should get the work done. I still have to send these to the mailing list, no word from fd.o yet. Cheers, Patrik Patrik Flykt (3): libsystemd-dhcp: Add capabilitye to print out test steps libsystemd-dhcp: Factor out test code for DHCP message verification libsystemd-dhcp: Add a full DHCP address acquisition test case src/libsystemd-dhcp/test-dhcp-client.c | 267 - 1 file changed, 260 insertions(+), 7 deletions(-) -- 1.8.5.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] libsystemd-dhcp: Add a full DHCP address acquisition test case
Upon startup the DHCP library will immediately send a DHCP Discover.
Handle the additional DHCP Discover checking and DHCP Offer sending
in test_addr_acq_recv_discover(). Write a zero UDP checksum, the
received XID and the faked MAC address into place to create a DHCP
message the library can accept.
Follow exactly the same steps when receiving a DHCP Request in
test_addr_acq_recv_request() and send the Ack. Check that the proper
addresses have been found by the DHCP library before exiting the
main loop and finishing the test.
---
src/libsystemd-dhcp/test-dhcp-client.c | 219 +
1 file changed, 219 insertions(+)
diff --git a/src/libsystemd-dhcp/test-dhcp-client.c
b/src/libsystemd-dhcp/test-dhcp-client.c
index e06f581..005d6c2 100644
--- a/src/libsystemd-dhcp/test-dhcp-client.c
+++ b/src/libsystemd-dhcp/test-dhcp-client.c
@@ -43,6 +43,7 @@ typedef int (*test_callback_recv_t)(size_t size, DHCPMessage
*dhcp);
static bool verbose = false;
static int test_fd[2];
static test_callback_recv_t callback_recv;
+static be32_t xid;
static void test_request_basic(sd_event *e)
{
@@ -262,6 +263,223 @@ static void test_discover_message(sd_event *e)
callback_recv = NULL;
}
+static uint8_t test_addr_acq_offer[] = {
+0x45, 0x10, 0x01, 0x48, 0x00, 0x00, 0x00, 0x00,
+0x80, 0x11, 0xb3, 0x84, 0xc0, 0xa8, 0x02, 0x01,
+0xc0, 0xa8, 0x02, 0xbf, 0x00, 0x43, 0x00, 0x44,
+0x01, 0x34, 0x00, 0x00, 0x02, 0x01, 0x06, 0x00,
+0x6f, 0x95, 0x2f, 0x30, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0xc0, 0xa8, 0x02, 0xbf,
+0xc0, 0xa8, 0x02, 0x01, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x63, 0x82, 0x53, 0x63, 0x35, 0x01, 0x02, 0x36,
+0x04, 0xc0, 0xa8, 0x02, 0x01, 0x33, 0x04, 0x00,
+0x00, 0x02, 0x58, 0x01, 0x04, 0xff, 0xff, 0xff,
+0x00, 0x2a, 0x04, 0xc0, 0xa8, 0x02, 0x01, 0x0f,
+0x09, 0x6c, 0x61, 0x62, 0x2e, 0x69, 0x6e, 0x74,
+0x72, 0x61, 0x03, 0x04, 0xc0, 0xa8, 0x02, 0x01,
+0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+};
+
+static uint8_t test_addr_acq_ack[] = {
+0x45, 0x10, 0x01, 0x48, 0x00, 0x00, 0x00, 0x00,
+0x80, 0x11, 0xb3, 0x84, 0xc0, 0xa8, 0x02, 0x01,
+0xc0, 0xa8, 0x02, 0xbf, 0x00, 0x43, 0x00, 0x44,
+0x01, 0x34, 0x00, 0x00, 0x02, 0x01, 0x06, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0xc0, 0xa8, 0x02, 0xbf,
+0xc0, 0xa8, 0x02, 0x01, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00,
[systemd-devel] [PATCH 1/3] libsystemd-dhcp: Add capability to print out test steps
---
src/libsystemd-dhcp/test-dhcp-client.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/libsystemd-dhcp/test-dhcp-client.c
b/src/libsystemd-dhcp/test-dhcp-client.c
index f341b3c..32c79eb 100644
--- a/src/libsystemd-dhcp/test-dhcp-client.c
+++ b/src/libsystemd-dhcp/test-dhcp-client.c
@@ -38,6 +38,7 @@ static struct ether_addr mac_addr = {
.ether_addr_octet = {'A', 'B', 'C', '1', '2', '3'}
};
+static bool verbose = false;
static int test_fd[2];
static void test_request_basic(sd_event *e)
@@ -46,6 +47,9 @@ static void test_request_basic(sd_event *e)
sd_dhcp_client *client;
+if (verbose)
+printf(* %s\n, __FUNCTION__);
+
r = sd_dhcp_client_new(client);
assert(r = 0);
@@ -126,6 +130,9 @@ static void test_checksum(void)
0xff, 0xff, 0xff, 0xff
};
+if (verbose)
+printf(* %s\n, __FUNCTION__);
+
assert(client_checksum(buf, 20) == be16toh(0x78ae));
}
@@ -207,6 +214,9 @@ static void test_discover_message(sd_event *e)
sd_dhcp_client *client;
int res, r;
+if (verbose)
+printf(* %s\n, __FUNCTION__);
+
r = sd_dhcp_client_new(client);
assert(r = 0);
assert(client);
--
1.8.5.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
Hi, On Tue, 2014-02-18 at 03:26 +0100, Lennart Poettering wrote: Kay, Zbigniew, Tom, David, Patrik, anything left to fix before I roll a release? I'd like to roll the release tomorrow (tuesday) or wednesday. Please have a closer look and test! I'm fine with the DHCP state of affairs and all the hard work from Tom. I (finally!) created an initial client side test case that should have hit the mailing list already. If that one still makes it to the release, I'm more than happy! Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/3] Add basic DHCP client test case
On Tue, Feb 18, 2014 at 3:07 PM, Patrik Flykt patrik.fl...@linux.intel.com wrote: To celebrate the upcoming release, here is a test case that runs the basic client side DHCP Discover-Offer-Request-ACK sequence (patch 03). This test should catch any major breakages with the client implementation. Of course more tests are needed, but let's start with this one. Awesome! Thanks for this. Applied. Patch 01 implements some pretty-printing, should one like to have a more verbose output of what's going on, perhaps using a future command line switch or so. Patch 02 factors out the code such that the actual test sequence in patch 03 is easier to implement. It's not the prettiest solution in the world but should get the work done. I still have to send these to the mailing list, no word from fd.o yet. I'll poke them (again) to see what's up. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fix SECCOMP_CFLAGS usage
On Tue, Feb 18, 2014 at 10:56:36AM -0300, Cristian Rodríguez wrote: SECCOMP_CFLAGS must be in the global CFLAGS as seccomp.h is included in core/execute.h. when seccomp.h is not in the standard path.(i.e openSUSE has it in /usr/include/pkg/libseccomp/, precisely to catch this kind of bugs) compiling systemd fails. --- Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile.am b/Makefile.am index 79c49e6..18df645 100644 --- a/Makefile.am +++ b/Makefile.am @@ -196,6 +196,7 @@ AM_CPPFLAGS = \ -I $(top_srcdir)/src/libsystemd/sd-bus \ -I $(top_srcdir)/src/libsystemd/sd-event \ -I $(top_srcdir)/src/libsystemd/sd-rtnl \ + $(SECCOMP_CFLAGS) \ $(OUR_CPPFLAGS) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] NEWS: Fix header file name
--- Minor correction to the news section. Cheers, Patrik NEWS | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index 4c7fb72..b40d369 100644 --- a/NEWS +++ b/NEWS @@ -85,8 +85,8 @@ CHANGES WITH 209: around the route netlink interface of the kernel, similar in style to sd-bus.h. -* A new API sd-dhcp.h has been added that provides a small - DHCPv4 client-side implementation. This is used by +* A new API sd-dhcp-client.h has been added that provides a + small DHCPv4 client-side implementation. This is used by systemd-networkd. * There is a new kernel command line option @@ -237,8 +237,8 @@ CHANGES WITH 209: sd-bus.h, sd-memfd.h, sd-event.h, sd-rtnl.h, sd-resolve.h, sd-utf8.h are found in this library as well, however are subject to the --enable-kdbus switch (see - below). Note that sd-dhcp.h and sd-daemon.h are not part - of this library (the former because it only consumes, + below). Note that sd-dhcp-client.h and sd-daemon.h are not + part of this library (the former because it only consumes, never provides, services of/to other APIs, and the latter because it is completely standalone). To make the transition easy from the separate libraries to the unified one, we -- 1.8.5.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] NEWS: Fix header file name
On Tue, Feb 18, 2014 at 3:30 PM, Patrik Flykt patrik.fl...@linux.intel.com wrote: --- Minor correction to the news section. Applied. Thanks! -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: machinectl: there is no command 'kill-machine'
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com --- man/machinectl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/machinectl.xml b/man/machinectl.xml index 5c30c44..ca4d52b 100644 --- a/man/machinectl.xml +++ b/man/machinectl.xml @@ -163,7 +163,7 @@ termoption--kill-who=/option/term listitemparaWhen used with -commandkill-machine/command, +commandkill/command, choose which processes to kill. Must be one of optionleader/option, or optionall/option to select whether @@ -178,7 +178,7 @@ termoption--signal=/option/term listitemparaWhen used with -commandkill-machine/command, choose +commandkill/command, choose which signal to send to selected processes. Must be one of the well-known signal specifiers, such as -- 1.8.5.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Set loaded_policy in smack_setup()
On Tue, 18.02.14 14:39, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Do you have any plans to push the commit[1] upstream? Footnotes: [1] http://article.gmane.org/gmane.comp.sysutils.systemd.devel/15596 [2] https://review.tizen.org/git/?p=platform/upstream/systemd.git;a=commitdiff;h=8445e9990936244ccb0a1023baa5abf77f3ae2c4 Both patches look pretty OK. [1] is entirely OK. Regarding [2]: - Tabs vs. spaces - Please do not do #defines for /dev. Also, do not hardcode the length like this. Instead use sizeof(/dev/)-1 or so. That said, best is actually to just use path_startswith(). Other than that looks fine... 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] Set loaded_policy in smack_setup()
-Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, February 18, 2014 8:19 AM To: Łukasz Stelmach Cc: Schaufler, Casey; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Set loaded_policy in smack_setup() On Tue, 18.02.14 14:39, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Do you have any plans to push the commit[1] upstream? Commit[1] depends on a change to libsmack that is still under discussion. It shouldn't get pushed until the libsmack changes are in. Footnotes: [1] http://article.gmane.org/gmane.comp.sysutils.systemd.devel/15596 [2] https://review.tizen.org/git/?p=platform/upstream/systemd.git;a=commitdi ff;h=8445e9990936244ccb0a1023baa5abf77f3ae2c4 Both patches look pretty OK. [1] is entirely OK. Regarding [2]: - Tabs vs. spaces - Please do not do #defines for /dev. Also, do not hardcode the length like this. Instead use sizeof(/dev/)-1 or so. That said, best is actually to just use path_startswith(). Other than that looks fine... 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] Set loaded_policy in smack_setup()
-Original Message- From: Schaufler, Casey Sent: Tuesday, February 18, 2014 8:27 AM To: Lennart Poettering; Łukasz Stelmach Cc: systemd-devel@lists.freedesktop.org; Schaufler, Casey Subject: RE: [systemd-devel] [PATCH] Set loaded_policy in smack_setup() -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, February 18, 2014 8:19 AM To: Łukasz Stelmach Cc: Schaufler, Casey; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Set loaded_policy in smack_setup() On Tue, 18.02.14 14:39, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Do you have any plans to push the commit[1] upstream? Commit[1] depends on a change to libsmack that is still under discussion. It shouldn't get pushed until the libsmack changes are in. Whoops! My mistake. There is no libsmack dependency. I misread the code. This should be fine to take at some point. Footnotes: [1] http://article.gmane.org/gmane.comp.sysutils.systemd.devel/15596 [2] https://review.tizen.org/git/?p=platform/upstream/systemd.git;a=commitdi ff;h=8445e9990936244ccb0a1023baa5abf77f3ae2c4 Both patches look pretty OK. [1] is entirely OK. Regarding [2]: - Tabs vs. spaces - Please do not do #defines for /dev. Also, do not hardcode the length like this. Instead use sizeof(/dev/)-1 or so. That said, best is actually to just use path_startswith(). Other than that looks fine... 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] Set loaded_policy in smack_setup()
On Tue, 18.02.14 16:37, Schaufler, Casey (casey.schauf...@intel.com) wrote: -Original Message- From: Schaufler, Casey Sent: Tuesday, February 18, 2014 8:27 AM To: Lennart Poettering; Łukasz Stelmach Cc: systemd-devel@lists.freedesktop.org; Schaufler, Casey Subject: RE: [systemd-devel] [PATCH] Set loaded_policy in smack_setup() -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, February 18, 2014 8:19 AM To: Łukasz Stelmach Cc: Schaufler, Casey; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Set loaded_policy in smack_setup() On Tue, 18.02.14 14:39, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Do you have any plans to push the commit[1] upstream? Commit[1] depends on a change to libsmack that is still under discussion. It shouldn't get pushed until the libsmack changes are in. Whoops! My mistake. There is no libsmack dependency. I misread the code. This should be fine to take at some point. Ah, OK. Could you fix the issues I pointed out in that other mail then and rebase, please? Will merge them then! 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] [HEADS-UP] It's release time!
2014-02-18 3:26 GMT+01:00 Lennart Poettering lenn...@poettering.net: Heya! It's release time again! It has been more than 4 months now since the last release. That's kinda emberassing, since we actually intended to go for a 2-3 week cycle... The big dbus transition took some time however. Aynway, I just finished a review of the git history, marked backportable fixes, and put together the NEWS. Kay, Zbigniew, Tom, David, Patrik, anything left to fix before I roll a release? I'd like to roll the release tomorrow (tuesday) or wednesday. Please have a closer look and test! I'm running into test-suite failures with current git master. I'm basically running git clean -xdf ./autogen.sh g make make check this results in .. ./build-aux/test-driver: line 107: 17839 Aborted $@ $log_file 21 FAIL: test-cgroup-mask .. Testsuite summary for systemd 208 # TOTAL: 74 # PASS: 68 # SKIP: 5 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to http://bugs.freedesktop.org/enter_bug.cgi?product=systemd make[4]: *** [test-suite.log] Error 1 make[3]: *** [check-TESTS] Error 2 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 What's interesting, running (as root) sudo make check I get two failing tests: ./build-aux/test-driver: line 107: 18426 Aborted $@ $log_file 21 FAIL: test-unit-name ./build-aux/test-driver: line 107: 18519 Aborted $@ $log_file 21 FAIL: test-cgroup-mask and the test-suite gets stuck in /usr/bin/perl ./test/udev-test.pl -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
2014-02-18 18:36 GMT+01:00 Michael Biebl mbi...@gmail.com: What's interesting, running (as root) sudo make check I get two failing tests: ./build-aux/test-driver: line 107: 18426 Aborted $@ $log_file 21 FAIL: test-unit-name ./build-aux/test-driver: line 107: 18519 Aborted $@ $log_file 21 FAIL: test-cgroup-mask and the test-suite gets stuck in /usr/bin/perl ./test/udev-test.pl Small correction. Letting the test/udev-test.pl test run for a few minutes, it finally fails, leading to Testsuite summary for systemd 208 # TOTAL: 74 # PASS: 65 # SKIP: 6 # XFAIL: 0 # FAIL: 3 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to http://bugs.freedesktop.org/enter_bug.cgi?product=systemd make[4]: *** [test-suite.log] Error 1 make[3]: *** [check-TESTS] Error 2 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sd-bus: the bus returned should be the first arg
This matches the API of previous headers, such as sd-journal.h.
---
TODO | 2 --
src/libsystemd/sd-bus/bus-util.c | 8
src/libsystemd/sd-bus/sd-bus.c | 4 ++--
src/machine/machinectl.c | 2 +-
src/systemd/sd-bus.h | 4 ++--
5 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/TODO b/TODO
index e74aa7e..63f3f7e 100644
--- a/TODO
+++ b/TODO
@@ -29,8 +29,6 @@ Preparation for 209:
* Review new libraries
-* libsystemd-journal returns the object created as first param in
sd_journal_new(), sd_bus_new() and suchlike as last...
-
Features:
* implement Distribute= in socket units to allow running multiple
diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c
index a468bca..8a6a70c 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -1054,11 +1054,11 @@ int bus_open_transport(BusTransport transport, const
char *host, bool user, sd_b
break;
case BUS_TRANSPORT_REMOTE:
-r = sd_bus_open_system_remote(host, bus);
+r = sd_bus_open_system_remote(bus, host);
break;
case BUS_TRANSPORT_CONTAINER:
-r = sd_bus_open_system_container(host, bus);
+r = sd_bus_open_system_container(bus, host);
break;
default:
@@ -1089,11 +1089,11 @@ int bus_open_transport_systemd(BusTransport transport,
const char *host, bool us
break;
case BUS_TRANSPORT_REMOTE:
-r = sd_bus_open_system_remote(host, bus);
+r = sd_bus_open_system_remote(bus, host);
break;
case BUS_TRANSPORT_CONTAINER:
-r = sd_bus_open_system_container(host, bus);
+r = sd_bus_open_system_container(bus, host);
break;
default:
diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
index 1187690..9b9a2a1 100644
--- a/src/libsystemd/sd-bus/sd-bus.c
+++ b/src/libsystemd/sd-bus/sd-bus.c
@@ -1214,7 +1214,7 @@ fail:
return r;
}
-_public_ int sd_bus_open_system_remote(const char *host, sd_bus **ret) {
+_public_ int sd_bus_open_system_remote(sd_bus **ret, const char *host) {
_cleanup_free_ char *e = NULL;
char *p = NULL;
sd_bus *bus;
@@ -1250,7 +1250,7 @@ _public_ int sd_bus_open_system_remote(const char *host,
sd_bus **ret) {
return 0;
}
-_public_ int sd_bus_open_system_container(const char *machine, sd_bus **ret) {
+_public_ int sd_bus_open_system_container(sd_bus **ret, const char *machine) {
_cleanup_free_ char *e = NULL;
sd_bus *bus;
char *p;
diff --git a/src/machine/machinectl.c b/src/machine/machinectl.c
index 3f4f8ac..ac2fbe3 100644
--- a/src/machine/machinectl.c
+++ b/src/machine/machinectl.c
@@ -618,7 +618,7 @@ static int login_machine(sd_bus *bus, char **args, unsigned
n) {
return -EIO;
}
-r = sd_bus_open_system_container(args[1], container_bus);
+r = sd_bus_open_system_container(container_bus, args[1]);
if (r 0) {
log_error(Failed to get container bus: %s, strerror(-r));
return r;
diff --git a/src/systemd/sd-bus.h b/src/systemd/sd-bus.h
index 34d4263..94a435ac 100644
--- a/src/systemd/sd-bus.h
+++ b/src/systemd/sd-bus.h
@@ -102,8 +102,8 @@ int sd_bus_default_system(sd_bus **ret);
int sd_bus_open(sd_bus **ret);
int sd_bus_open_user(sd_bus **ret);
int sd_bus_open_system(sd_bus **ret);
-int sd_bus_open_system_remote(const char *host, sd_bus **ret);
-int sd_bus_open_system_container(const char *machine, sd_bus **ret);
+int sd_bus_open_system_remote(sd_bus **ret, const char *host);
+int sd_bus_open_system_container(sd_bus **ret, const char *machine);
int sd_bus_new(sd_bus **ret);
int sd_bus_set_address(sd_bus *bus, const char *address);
--
1.8.5.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] kdbus.txt: grammatical fixes
--- kdbus.txt | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/kdbus.txt b/kdbus.txt index a3d806b..de36672 100644 --- a/kdbus.txt +++ b/kdbus.txt @@ -6,7 +6,7 @@ all communication between processes take place over special character device nodes in /dev/kdbus/. For the general D-Bus protocol specification, the payload format, the -marshaling, the communication semantics, please refer to: +marshaling, and the communication semantics, please refer to: http://dbus.freedesktop.org/doc/dbus-specification.html For a kdbus specific userspace library implementation please refer to: @@ -21,28 +21,28 @@ Terminology === Domain: A domain is a named object containing a number of buses. A system -container which contains its own init system and users usually also +container that contains its own init system and users usually also runs in its own kdbus domain. The /dev/kdbus/domain/container-name/ directory shows up inside the domain as /dev/kdbus/. Every domain offers a control device node to create new buses or domains. -Domains have no connection to each other, cannot see or talk to +Domains have no connection to each other and cannot see nor talk to each other. Only from the initial domain, given the process has the -needed access rights, the device nodes inside of other domains -can be seen. +required access rights, can the device nodes inside of other domains +be seen. Bus: A bus is a named object inside a domain. Clients exchange messages -over a bus. Multiple buses themselves have no connection to each other, +over a bus. Multiple buses themselves have no connection to each other; messages are only exchanged on the same bus. The default entry point to a bus, where clients establish the connection to, is the bus device node /dev/kdbus/bus name/bus. Common operating system setups create one system bus per system, and one -user bus for every logged-in user. Applications or services can create -their own private named buses if they want to. +user bus for every logged-in user. Applications or services may create +their own private named buses. Endpoint: -An endpoint provides the device node to talk to a bus. Opening a the -enpoint creates a new connection to the bus the endpoint belongs to. +An endpoint provides the device node to talk to a bus. Opening an +endpoint creates a new connection to the bus to which the endpoint belongs. Every bus has a default endpoint called bus. A bus can optionally offer additional endpoints with custom names to provide a restricted access to the same bus. Custom endpoints carry @@ -51,24 +51,24 @@ Terminology Connection: A connection to a bus is created by opening an endpoint device node of -a bus, and becoming an active client with the HELLO exchange. Every -connected client connection has a unique identifier on the bus, and can +a bus and becoming an active client with the HELLO exchange. Every +connected client connection has a unique identifier on the bus and can address messages to every other connection on the same bus by using the peer's connection id as the destination. Well-known Name: A connection can, in addition to its implicit unique connection id, request the ownership of a textual well-known name. Well-known names are noted -in reverse-domain notation like com.example.service. Connections offering +in reverse-domain notation, such as com.example.service. Connections offering a service on a bus are usually reached by its well-known name. The analogy of connection id and well-known name is an IP address and a DNS name associated with that address. Message: Connections can exchange messages with other connections by addressing -the peers with their connection id or well-known name. A message consist -of a message header with kernel-specific information how to route the -message, and the message payload which is a logical byte stream of +the peers with their connection id or well-known name. A message consists +of a message header with kernel-specific information on how to route the +message, and the message payload, which is a logical byte stream of arbitrary size. Messages can carry additional file descriptors to be passed from one connection to another. Every connection can specify which set of metadata the kernel should attach to the message when it is delivered -- 1.8.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn: allow 32-bit chroots from 64-bit hosts
Arch Linux uses nspawn as a container for building packages and needs
to be able to start a 32bit chroot from a 64bit host. 24fb11120756
disrupted this feature when seccomp handling was added.
---
Lennart suggested this approach, and it works nicely.
src/nspawn/nspawn.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 089af07..5a2467d 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1539,6 +1539,14 @@ static int audit_still_doesnt_work_in_containers(void) {
goto finish;
}
+#ifdef __x86_64__
+r = seccomp_arch_add(seccomp, SCMP_ARCH_X86);
+if (r 0 r != -EEXIST) {
+log_error(Failed to add x86 to seccomp filter: %s,
strerror(-r));
+goto finish;
+}
+#endif
+
r = seccomp_load(seccomp);
if (r 0)
log_error(Failed to install seccomp audit filter: %s,
strerror(-r));
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nspawn: allow 32-bit chroots from 64-bit hosts
On Tue, Feb 18, 2014 at 02:44:14PM -0500, Dave Reisner wrote:
Arch Linux uses nspawn as a container for building packages and needs
to be able to start a 32bit chroot from a 64bit host. 24fb11120756
disrupted this feature when seccomp handling was added.
---
Lennart suggested this approach, and it works nicely.
I suppose it's also possible to run an x32 chroot from an x86_64 host,
so we might want to allow that. Alternatively, it seems we can just
change the default action to allow (instead of kill) when a bad
architecture is encountered. I don't know if there's side effects with
that change that we'd want to avoid.
src/nspawn/nspawn.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 089af07..5a2467d 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1539,6 +1539,14 @@ static int audit_still_doesnt_work_in_containers(void)
{
goto finish;
}
+#ifdef __x86_64__
+r = seccomp_arch_add(seccomp, SCMP_ARCH_X86);
+if (r 0 r != -EEXIST) {
+log_error(Failed to add x86 to seccomp filter: %s,
strerror(-r));
+goto finish;
+}
+#endif
+
r = seccomp_load(seccomp);
if (r 0)
log_error(Failed to install seccomp audit filter: %s,
strerror(-r));
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] It's release time!
On Tue, 18.02.14 18:36, Michael Biebl (mbi...@gmail.com) wrote: 2014-02-18 3:26 GMT+01:00 Lennart Poettering lenn...@poettering.net: Heya! It's release time again! It has been more than 4 months now since the last release. That's kinda emberassing, since we actually intended to go for a 2-3 week cycle... The big dbus transition took some time however. Aynway, I just finished a review of the git history, marked backportable fixes, and put together the NEWS. Kay, Zbigniew, Tom, David, Patrik, anything left to fix before I roll a release? I'd like to roll the release tomorrow (tuesday) or wednesday. Please have a closer look and test! I'm running into test-suite failures with current git master. I'm basically running git clean -xdf ./autogen.sh g make make check this results in .. ./build-aux/test-driver: line 107: 17839 Aborted $@ $log_file 21 FAIL: test-cgroup-mask Hmm, the fialing tests all require write access to the cgroupfs, and if they don't get they get automatically skipped. Are you running this as root? If you run test-cgroup-mask on the command line, how does it fail, can you paste the output? 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 1/2] machinectl: add bash completion
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
---
Makefile.am | 3 ++
man/machinectl.xml | 8
shell-completion/bash/machinectl | 97
src/machine/machinectl.c | 14 +-
4 files changed, 120 insertions(+), 2 deletions(-)
create mode 100644 shell-completion/bash/machinectl
diff --git a/Makefile.am b/Makefile.am
index 18df645..83c70a6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3951,6 +3951,9 @@ machinectl_LDADD = \
rootbin_PROGRAMS += \
machinectl
+dist_bashcompletion_DATA += \
+ shell-completion/bash/machinectl
+
test_machine_tables_SOURCES = \
src/machine/test-machine-tables.c
diff --git a/man/machinectl.xml b/man/machinectl.xml
index ca4d52b..9eb45dc 100644
--- a/man/machinectl.xml
+++ b/man/machinectl.xml
@@ -95,6 +95,14 @@
/varlistentry
varlistentry
+termoption--no-legend/option/term
+
+listitemparaDo not print the legend,
+i.e. the column headers and the
+footer./para/listitem
+/varlistentry
+
+varlistentry
termoption--no-ask-password/option/term
listitemparaDo not query the user
diff --git a/shell-completion/bash/machinectl b/shell-completion/bash/machinectl
new file mode 100644
index 000..3789492
--- /dev/null
+++ b/shell-completion/bash/machinectl
@@ -0,0 +1,97 @@
+# machinectl(1) completion -*- shell-script -*-
+#
+# This file is part of systemd.
+#
+# Copyright 2014 Thomas H.P. Andersen
+#
+# 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
+# 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/.
+
+__contains_word() {
+local w word=$1; shift
+for w in $@; do
+[[ $w = $word ]] return
+done
+}
+
+__get_machines() {
+local a b
+machinectl list --no-legend --no-pager | { while read a b; do echo
$a; done; };
+}
+
+_machinectl() {
+local cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]}
+local i verb comps
+
+local -A OPTS=(
+ [STANDALONE]='--all -a --full --help -h --no-ask-password
--no-legend --no-pager --version'
+ [ARG]='--host -H --kill-who -M --machine --property -p
--signal -s'
+)
+
+local -A VERBS=(
+ [STANDALONE]='list'
+ [MACHINES]='status show terminate kill reboot login'
+)
+
+_init_completion || return
+
+for ((i=0; i = COMP_CWORD; i++)); do
+if __contains_word ${COMP_WORDS[i]} ${VERBS[*]}
+ ! __contains_word ${COMP_WORDS[i-1]} ${OPTS[ARG]}; then
+verb=${COMP_WORDS[i]}
+break
+fi
+done
+
+if __contains_word $prev ${OPTS[ARG]}; then
+case $prev in
+--signal|-s)
+comps=$(compgen -A signal)
+;;
+--kill-who)
+comps='all leader'
+;;
+--host|-H)
+comps=$(compgen -A hostname)
+;;
+--machine|-M)
+comps=$( __get_machines )
+;;
+--property|-p)
+comps=''
+;;
+esac
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+fi
+
+if [[ $cur = -* ]]; then
+COMPREPLY=( $(compgen -W '${OPTS[*]}' -- $cur) )
+return 0
+fi
+
+if [[ -z $verb ]]; then
+comps=${VERBS[*]}
+
+elif __contains_word $verb ${VERBS[STANDALONE]}; then
+comps=''
+
+elif __contains_word $verb ${VERBS[MACHINES]}; then
+comps=$( __get_machines )
+fi
+
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+}
+
+complete -F _machinectl machinectl
diff --git a/src/machine/machinectl.c b/src/machine/machinectl.c
index 3f4f8ac..912cffd
[systemd-devel] [PATCH 2/2] machinectl: remove unused --no-ask-password
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
---
man/machinectl.xml | 8
src/machine/machinectl.c | 8
2 files changed, 16 deletions(-)
diff --git a/man/machinectl.xml b/man/machinectl.xml
index 9eb45dc..89ab474 100644
--- a/man/machinectl.xml
+++ b/man/machinectl.xml
@@ -103,14 +103,6 @@
/varlistentry
varlistentry
-termoption--no-ask-password/option/term
-
-listitemparaDo not query the user
-for authentication for privileged
-operations./para/listitem
-/varlistentry
-
-varlistentry
termoption-H/option/term
termoption--host=/option/term
diff --git a/src/machine/machinectl.c b/src/machine/machinectl.c
index 912cffd..de79996 100644
--- a/src/machine/machinectl.c
+++ b/src/machine/machinectl.c
@@ -49,7 +49,6 @@ static bool arg_no_pager = false;
static bool arg_legend = true;
static const char *arg_kill_who = NULL;
static int arg_signal = SIGTERM;
-static bool arg_ask_password = true;
static BusTransport arg_transport = BUS_TRANSPORT_LOCAL;
static char *arg_host = NULL;
@@ -677,7 +676,6 @@ static int help(void) {
--version Show package version\n
--no-pager Do not pipe output into a pager\n
--no-legend Do not show the headers and footers\n
---no-ask-password Don't prompt for password\n
-H --host=[USER@]HOST Operate on remote host\n
-M --machine=CONTAINER Operate on local container\n
-p --property=NAME Show only properties by this name\n
@@ -705,7 +703,6 @@ static int parse_argv(int argc, char *argv[]) {
ARG_NO_PAGER,
ARG_NO_LEGEND,
ARG_KILL_WHO,
-ARG_NO_ASK_PASSWORD,
};
static const struct option options[] = {
@@ -720,7 +717,6 @@ static int parse_argv(int argc, char *argv[]) {
{ signal, required_argument, NULL, 's'
},
{ host,required_argument, NULL, 'H'
},
{ machine, required_argument, NULL, 'M'
},
-{ no-ask-password, no_argument, NULL,
ARG_NO_ASK_PASSWORD },
{}
};
@@ -768,10 +764,6 @@ static int parse_argv(int argc, char *argv[]) {
arg_legend = false;
break;
-case ARG_NO_ASK_PASSWORD:
-arg_ask_password = false;
-break;
-
case ARG_KILL_WHO:
arg_kill_who = optarg;
break;
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] machinectl: remove unused --no-ask-password
On Tue, 18.02.14 21:09, Thomas H.P. Andersen (pho...@gmail.com) wrote:
Applied both! Thanks!
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
---
man/machinectl.xml | 8
src/machine/machinectl.c | 8
2 files changed, 16 deletions(-)
diff --git a/man/machinectl.xml b/man/machinectl.xml
index 9eb45dc..89ab474 100644
--- a/man/machinectl.xml
+++ b/man/machinectl.xml
@@ -103,14 +103,6 @@
/varlistentry
varlistentry
-
termoption--no-ask-password/option/term
-
-listitemparaDo not query the user
-for authentication for privileged
-operations./para/listitem
-/varlistentry
-
-varlistentry
termoption-H/option/term
termoption--host=/option/term
diff --git a/src/machine/machinectl.c b/src/machine/machinectl.c
index 912cffd..de79996 100644
--- a/src/machine/machinectl.c
+++ b/src/machine/machinectl.c
@@ -49,7 +49,6 @@ static bool arg_no_pager = false;
static bool arg_legend = true;
static const char *arg_kill_who = NULL;
static int arg_signal = SIGTERM;
-static bool arg_ask_password = true;
static BusTransport arg_transport = BUS_TRANSPORT_LOCAL;
static char *arg_host = NULL;
@@ -677,7 +676,6 @@ static int help(void) {
--version Show package version\n
--no-pager Do not pipe output into a pager\n
--no-legend Do not show the headers and
footers\n
---no-ask-password Don't prompt for password\n
-H --host=[USER@]HOST Operate on remote host\n
-M --machine=CONTAINER Operate on local container\n
-p --property=NAME Show only properties by this name\n
@@ -705,7 +703,6 @@ static int parse_argv(int argc, char *argv[]) {
ARG_NO_PAGER,
ARG_NO_LEGEND,
ARG_KILL_WHO,
-ARG_NO_ASK_PASSWORD,
};
static const struct option options[] = {
@@ -720,7 +717,6 @@ static int parse_argv(int argc, char *argv[]) {
{ signal, required_argument, NULL, 's'
},
{ host,required_argument, NULL, 'H'
},
{ machine, required_argument, NULL, 'M'
},
-{ no-ask-password, no_argument, NULL,
ARG_NO_ASK_PASSWORD },
{}
};
@@ -768,10 +764,6 @@ static int parse_argv(int argc, char *argv[]) {
arg_legend = false;
break;
-case ARG_NO_ASK_PASSWORD:
-arg_ask_password = false;
-break;
-
case ARG_KILL_WHO:
arg_kill_who = optarg;
break;
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] nspawn: allow 32-bit chroots from 64-bit hosts
On 02/18/2014 11:52 AM, Dave Reisner wrote: On Tue, Feb 18, 2014 at 02:44:14PM -0500, Dave Reisner wrote: Arch Linux uses nspawn as a container for building packages and needs to be able to start a 32bit chroot from a 64bit host. 24fb11120756 disrupted this feature when seccomp handling was added. --- Lennart suggested this approach, and it works nicely. I suppose it's also possible to run an x32 chroot from an x86_64 host, so we might want to allow that. Alternatively, it seems we can just change the default action to allow (instead of kill) when a bad architecture is encountered. I don't know if there's side effects with that change that we'd want to avoid. And if you're on a 64-bit kernel with a 32-bit userspace (either i386 or x32), you can launch a 64-bit chroot if you want to. As such #ifdef __x86_64__ seems wrong. -hpa ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nspawn: allow 32-bit chroots from 64-bit hosts
On Tue, 18.02.14 13:45, H. Peter Anvin (h...@zytor.com) wrote: On 02/18/2014 11:52 AM, Dave Reisner wrote: On Tue, Feb 18, 2014 at 02:44:14PM -0500, Dave Reisner wrote: Arch Linux uses nspawn as a container for building packages and needs to be able to start a 32bit chroot from a 64bit host. 24fb11120756 disrupted this feature when seccomp handling was added. --- Lennart suggested this approach, and it works nicely. I suppose it's also possible to run an x32 chroot from an x86_64 host, so we might want to allow that. Alternatively, it seems we can just change the default action to allow (instead of kill) when a bad architecture is encountered. I don't know if there's side effects with that change that we'd want to avoid. And if you're on a 64-bit kernel with a 32-bit userspace (either i386 or x32), you can launch a 64-bit chroot if you want to. As such #ifdef __x86_64__ seems wrong. Hmm, if we think about that, how would that even work? I mean, you probably want to fix the personality in that case, right? The personality API appears to have two rules: a) On a system with a 32bit kernel PER_LINUX translates to the 32bit personality, and PER_LINUX32 is kinda pointless (did I get this right?) b) On a system with a 64bit kernel PER_LINUX translates to the 64bit personality, and PER_LINUX32 to the 32bit personality that is also supported. Now, let's say we are on a 64bit kernel and a 32bit userspace. And now want to invoke a 64bit chroot. How would we fix the personality? I mean, from that context rule a) would apply, hence there is no way to upgrade the personality to 64bit, is there? Or does personality(PER_LINUX) do two completely different things if I am calling it from a 32bit userspace on a 32bit kernel and a 32bit userspace on a 64bit kernel? 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] nspawn: allow 32-bit chroots from 64-bit hosts
On Tue, 18.02.14 14:44, Dave Reisner (dreis...@archlinux.org) wrote:
Arch Linux uses nspawn as a container for building packages and needs
to be able to start a 32bit chroot from a 64bit host. 24fb11120756
disrupted this feature when seccomp handling was added.
As mentioned on IRC. I have commited this and then generalized this and
used it for executing services, too.
---
Lennart suggested this approach, and it works nicely.
src/nspawn/nspawn.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 089af07..5a2467d 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1539,6 +1539,14 @@ static int audit_still_doesnt_work_in_containers(void)
{
goto finish;
}
+#ifdef __x86_64__
+r = seccomp_arch_add(seccomp, SCMP_ARCH_X86);
+if (r 0 r != -EEXIST) {
+log_error(Failed to add x86 to seccomp filter: %s,
strerror(-r));
+goto finish;
+}
+#endif
+
r = seccomp_load(seccomp);
if (r 0)
log_error(Failed to install seccomp audit filter: %s,
strerror(-r));
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 2 commits - man/systemd-networkd.service.xml man/udev.xml src/network src/udev TODO
On Tue, Feb 18, 2014 at 01:34:24PM -0800, Tom Gundersen wrote:
diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
index 48131c1..a470c22 100644
--- a/src/network/networkd-network.c
+++ b/src/network/networkd-network.c
@@ -178,7 +178,7 @@ int network_get(Manager *manager, struct udev_device
*device, Network **ret) {
network-match_name,
udev_device_get_sysattr_value(device, address),
udev_device_get_property_value(device, ID_PATH),
-udev_device_get_driver(device),
+
udev_device_get_driver(udev_device_get_parent(device)),
udev_device_get_devtype(device),
udev_device_get_sysname(device))) {
log_debug(%s: found matching network '%s',
diff --git a/src/udev/net/link-config.c b/src/udev/net/link-config.c
I think this requires some oom hadling, since udev_device_get_parent allocates
memory.
Even though udev_device_get_driver accepts NULL, wouldn't the result be correct?
index bd97cd8..3afaff1 100644
--- a/src/udev/net/link-config.c
+++ b/src/udev/net/link-config.c
@@ -244,7 +244,7 @@ int link_config_get(link_config_ctx *ctx, struct
udev_device *device, link_confi
link-match_driver, link-match_type,
NULL,
udev_device_get_sysattr_value(device,
address),
udev_device_get_property_value(device,
ID_PATH),
- udev_device_get_driver(device),
+
udev_device_get_driver(udev_device_get_parent(device)),
udev_device_get_devtype(device),
NULL)) {
log_debug(Config file %s applies to device %s,
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-bus: the bus returned should be the first arg
On Tue, Feb 18, 2014 at 07:11:08PM +0100, Jason A. Donenfeld wrote: This matches the API of previous headers, such as sd-journal.h. --- TODO | 2 -- src/libsystemd/sd-bus/bus-util.c | 8 src/libsystemd/sd-bus/sd-bus.c | 4 ++-- src/machine/machinectl.c | 2 +- src/systemd/sd-bus.h | 4 ++-- 5 files changed, 9 insertions(+), 11 deletions(-) diff --git a/TODO b/TODO index e74aa7e..63f3f7e 100644 --- a/TODO +++ b/TODO @@ -29,8 +29,6 @@ Preparation for 209: * Review new libraries -* libsystemd-journal returns the object created as first param in sd_journal_new(), sd_bus_new() and suchlike as last... - Features: * implement Distribute= in socket units to allow running multiple diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c index a468bca..8a6a70c 100644 --- a/src/libsystemd/sd-bus/bus-util.c +++ b/src/libsystemd/sd-bus/bus-util.c @@ -1054,11 +1054,11 @@ int bus_open_transport(BusTransport transport, const char *host, bool user, sd_b break; case BUS_TRANSPORT_REMOTE: -r = sd_bus_open_system_remote(host, bus); +r = sd_bus_open_system_remote(bus, host); break; Hi, I think Lennart meant a change the other way around, since the new policy is to have the return value as the last argument. But sd_j_* functions are older and do not respect this rule. But changing them would require a break of the API, which, to me, is not worth it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-bus: the bus returned should be the first arg
On Wed, Feb 19, 2014 at 2:54 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Feb 18, 2014 at 07:11:08PM +0100, Jason A. Donenfeld wrote: I think Lennart meant a change the other way around, since the new policy is to have the return value as the last argument. But sd_j_* functions are older and do not respect this rule. But changing them would require a break of the API, which, to me, is not worth it. Additional parameters should be at the end, to allow varargs. Returning the new object as the last parameter is not a good rule for that reason. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] kdbus.txt: grammatical fixes
On Tue, Feb 18, 2014 at 8:32 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: --- kdbus.txt | 32 1 file changed, 16 insertions(+), 16 deletions(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] test-cgroup-mask: pass on kernels without memory controller
It seems that unit_get_siblings_mask returns the controllers
filtered by what is available, but get_members_mask and
get_cgroup_mask do not. This just fixes the test following the
symptoms, since I don't know what is the expected behaviour.
---
I haven't looked at the code recently... so I'm just throwing this
out there.
Zbyszek
src/core/cgroup.c | 2 +-
src/test/test-cgroup-mask.c | 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6c51235..707ce47 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -362,7 +362,7 @@ CGroupControllerMask unit_get_members_mask(Unit *u) {
if (member == u)
continue;
- if (UNIT_DEREF(member-slice) != u)
+if (UNIT_DEREF(member-slice) != u)
continue;
u-cgroup_members_mask |=
diff --git a/src/test/test-cgroup-mask.c b/src/test/test-cgroup-mask.c
index 3414ed4..cff7e8f 100644
--- a/src/test/test-cgroup-mask.c
+++ b/src/test/test-cgroup-mask.c
@@ -83,20 +83,20 @@ static int test_cgroup_mask(void) {
assert(unit_get_members_mask(root) == (CGROUP_CPU | CGROUP_CPUACCT |
CGROUP_BLKIO | CGROUP_MEMORY));
/* Verify aggregation of sibling masks. */
-assert(unit_get_siblings_mask(son) == (CGROUP_CPU | CGROUP_CPUACCT));
-assert(unit_get_siblings_mask(daughter) == (CGROUP_CPU |
CGROUP_CPUACCT));
+assert(unit_get_siblings_mask(son) == ((CGROUP_CPU | CGROUP_CPUACCT)
m-cgroup_supported));
+assert(unit_get_siblings_mask(daughter) == ((CGROUP_CPU |
CGROUP_CPUACCT) m-cgroup_supported));
assert(unit_get_siblings_mask(grandchild) == 0);
-assert(unit_get_siblings_mask(parent_deep) == (CGROUP_CPU |
CGROUP_CPUACCT));
-assert(unit_get_siblings_mask(parent) == (CGROUP_CPU | CGROUP_CPUACCT
| CGROUP_BLKIO));
-assert(unit_get_siblings_mask(root) == (CGROUP_CPU | CGROUP_CPUACCT |
CGROUP_BLKIO));
+assert(unit_get_siblings_mask(parent_deep) == ((CGROUP_CPU |
CGROUP_CPUACCT) m-cgroup_supported));
+assert(unit_get_siblings_mask(parent) == ((CGROUP_CPU | CGROUP_CPUACCT
| CGROUP_BLKIO) m-cgroup_supported));
+assert(unit_get_siblings_mask(root) == ((CGROUP_CPU | CGROUP_CPUACCT |
CGROUP_BLKIO) m-cgroup_supported));
/* Verify aggregation of target masks. */
-assert(unit_get_target_mask(son) == (CGROUP_CPU | CGROUP_CPUACCT));
-assert(unit_get_target_mask(daughter) == (CGROUP_CPU |
CGROUP_CPUACCT));
+assert(unit_get_target_mask(son) == ((CGROUP_CPU | CGROUP_CPUACCT)
m-cgroup_supported));
+assert(unit_get_target_mask(daughter) == ((CGROUP_CPU |
CGROUP_CPUACCT) m-cgroup_supported));
assert(unit_get_target_mask(grandchild) == 0);
-assert(unit_get_target_mask(parent_deep) == (CGROUP_CPU |
CGROUP_CPUACCT | CGROUP_MEMORY));
-assert(unit_get_target_mask(parent) == (CGROUP_CPU | CGROUP_CPUACCT |
CGROUP_BLKIO | CGROUP_MEMORY));
-assert(unit_get_target_mask(root) == (CGROUP_CPU | CGROUP_CPUACCT |
CGROUP_BLKIO | CGROUP_MEMORY));
+assert(unit_get_target_mask(parent_deep) == ((CGROUP_CPU |
CGROUP_CPUACCT | CGROUP_MEMORY) m-cgroup_supported));
+assert(unit_get_target_mask(parent) == ((CGROUP_CPU | CGROUP_CPUACCT |
CGROUP_BLKIO | CGROUP_MEMORY) m-cgroup_supported));
+assert(unit_get_target_mask(root) == ((CGROUP_CPU | CGROUP_CPUACCT |
CGROUP_BLKIO | CGROUP_MEMORY) m-cgroup_supported));
manager_free(m);
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
