Re: [systemd-devel] [systemd-commits] 2 commits - src/core src/journal-remote src/network
Hi, Zbigniew Jędrzejewski-Szmek: > > wrap a few *_FOREACH macros in curly braces > > > cppcheck is full of errors anyway. I don't think we should make the code > less pretty just to satisfy a checker, and a rarely used one. > While you may be right about cppcheck, IMHO it's good style to wrap all multi-line subordinates in curlies on general principle. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cycle between logind and NetworkManager in case of remote user database
NetworkManager sets logind inhibitor lock to monitor for suspend events. So it implicitly requires logind to be present when NM starts. logind is ordered after nss-user-lookup.target. If we have remote user database, it means that logind depends on network to be up and running. If network is provided by NetworkManager we have a loop. Due to the fact that NetworkManager service itself does not declare dependency on logind, it can be pretty hard to recognize. Any idea how it can be solved nicely? I can only think of delaying inhibitor logic in NM until logind is started. Not sure what side effects it may have. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Something is removing links from my *.wants/ directory
Yeah, something similar is happening. If I edit the container.target and add the Wants= instead of creating the .wants directory it works well. I think the preset-all is "syncing" the config with the .wants directory as well and removes all links which are not defined in the config. So editing the unit file solved my issue. Thanks! On Fri, Dec 12, 2014 at 3:43 PM, Colin Guthrie wrote: > Adam Papai wrote on 11/12/14 09:17: > > Why and what is removing my files from the target directories? Those are > > required to run the lxc-container properly otherwise it'll boot up in a > > dergaded state, without ssh and iptables forwarding and so on. > > > > What did I miss? Is it something change between 215 - 217? I debugged it > > with strace and lxc-start does nothing with those files. > > > > Any help is appreciated! > > Just as a random guess, systemctl preset-all is perhaps now run when > /etc/ is detected as empty as part of the first-boot stuff to initialise > /etc properly... perhaps this is to blame? > > Col > > > -- > > Colin Guthrie > gmane(at)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: > Tribalogic Limited http://www.tribalogic.net/ > Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ > -- Adam PAPAI E-mail: w...@wooh.hu Phone: +36 30 33-55-375 Web: http://www.wooh.hu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
The "in the field" problem is that after what firmware 1.7 changes with Intel network drivers or what not things broke due to the fact that network interfaces settings did not get inherited to the bridge interface and we need to avoid that problem, which is why I think we need to redefine how we fundamentally are defining type network devices On Sat, Dec 13, 2014, 00:20 Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Dec 12, 2014 at 04:07:23PM +0100, Lennart Poettering wrote: > > On Fri, 12.12.14 09:07, Rauta, Alin (alin.ra...@intel.com) wrote: > > > > > What do you think about the following transformations: > > > > > > [FDBEntry] => [FDBNeigh] > > > > We try to avoid acronyms and abbreviations unless they are very widely > > established. Hence I am not convinced "Neigh" is something we should > > use. > > > > Given that "fdb" and "entry" are commonly used I think [FDBEntry] > > would be fine. > I don't think it's widely established. E.g. compared to "VLAN", it > certainly isn't. "FDB" is also pretty much non-googlable. > "ForwardingDatabase" is imho much nicer and easier to > search for. Also, it's not like you type those things by hand every > day, so saving a few characters should not be a consideration. > > Zbyszek > ___ > 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] blkid: Warn when rejecting a superblock with a bad csum
On Fri, Dec 12, 2014 at 6:29 PM, Chris Atkinson wrote: > > Should the line: > > PKG_CHECK_MODULES(BLKID, [ blkid >= 2.24 ], > > instead read > > PKG_CHECK_MODULES(BLKID, [ blkid >= 2.25 ], > > instead since the commit message appears to mandate 2.25 not 2.24? > I made only necessary changes, patch review can be a conservative process. The patch uses a 2.24 feature. If the reqs for libmount and libblkid are bumped to 2.25 match the runtime dependency, I don't mind either way. (resent the patch to update the README) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] blkid: Warn when rejecting a superblock with a bad csum
Bump libblkid requirement from 2.20 to 2.24. util-linux 2.25 is actually required since fdbbad981cc5da8bb4ed7e9b6646e7a114745ec5 --- README| 2 +- configure.ac | 2 +- src/udev/udev-builtin-blkid.c | 13 - 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/README b/README index 9c80a56..73a09e4 100644 --- a/README +++ b/README @@ -109,11 +109,11 @@ REQUIREMENTS: glibc >= 2.14 libcap libmount >= 2.20 (from util-linux) libseccomp >= 1.0.0 (optional) -libblkid >= 2.20 (from util-linux) (optional) +libblkid >= 2.24 (from util-linux) (optional) libkmod >= 15 (optional) PAM >= 1.1.2 (optional) libcryptsetup (optional) libaudit (optional) libacl (optional) diff --git a/configure.ac b/configure.ac index 9218ed3..453f5de 100644 --- a/configure.ac +++ b/configure.ac @@ -430,11 +430,11 @@ AM_CONDITIONAL(HAVE_XKBCOMMON, [test "$have_xkbcommon" = "yes"]) # -- have_blkid=no AC_ARG_ENABLE(blkid, AS_HELP_STRING([--disable-blkid], [disable blkid support])) if test "x$enable_blkid" != "xno"; then -PKG_CHECK_MODULES(BLKID, [ blkid >= 2.20 ], +PKG_CHECK_MODULES(BLKID, [ blkid >= 2.24 ], [AC_DEFINE(HAVE_BLKID, 1, [Define if blkid is available]) have_blkid=yes], have_blkid=no) if test "x$have_blkid" = xno -a "x$enable_blkid" = xyes; then AC_MSG_ERROR([*** blkid support requested but libraries not found]) fi fi diff --git a/src/udev/udev-builtin-blkid.c b/src/udev/udev-builtin-blkid.c index 810f27d..83bd8c4 100644 --- a/src/udev/udev-builtin-blkid.c +++ b/src/udev/udev-builtin-blkid.c @@ -219,10 +219,11 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t bool noraid = false; _cleanup_close_ int fd = -1; blkid_probe pr; const char *data; const char *name; +const char *prtype = NULL; int nvals; int i; int err = 0; bool is_gpt = false; @@ -254,11 +255,12 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t return EXIT_FAILURE; blkid_probe_set_superblocks_flags(pr, BLKID_SUBLKS_LABEL | BLKID_SUBLKS_UUID | BLKID_SUBLKS_TYPE | BLKID_SUBLKS_SECTYPE | -BLKID_SUBLKS_USAGE | BLKID_SUBLKS_VERSION); +BLKID_SUBLKS_USAGE | BLKID_SUBLKS_VERSION | +BLKID_SUBLKS_BADCSUM); if (noraid) blkid_probe_filter_superblocks_usage(pr, BLKID_FLTR_NOTIN, BLKID_USAGE_RAID); fd = open(udev_device_get_devnode(dev), O_RDONLY|O_CLOEXEC); @@ -276,10 +278,19 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t noraid ? "no" : "", offset); err = probe_superblocks(pr); if (err < 0) goto out; +if (blkid_probe_has_value(pr, "SBBADCSUM")) { +if (!blkid_probe_lookup_value(pr, "TYPE", &prtype, NULL)) +log_warning("incorrect %s checksum on %s", +prtype, udev_device_get_devnode(dev)); +else +log_warning("incorrect checksum on %s", +udev_device_get_devnode(dev)); +goto out; +} /* If we are a partition then our parent passed on the root * partition UUID to us */ root_partition = udev_device_get_property_value(dev, "ID_PART_GPT_AUTO_ROOT_UUID"); -- 2.1.2.457.g0cd6422 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 2 commits - src/core src/journal-remote src/network
On Fri, Dec 12, 2014 at 12:58:04PM -0800, Thomas H.P. Andersen wrote: > Author: Thomas Hindoe Paaboel Andersen > Date: Fri Dec 12 19:51:41 2014 +0100 > > wrap a few *_FOREACH macros in curly braces > > cppcheck would give up with "syntax error" without them. This led > to reports of syntax errors in unrelated locations and potentially > hid other errors cppcheck is full of errors anyway. I don't think we should make the code less pretty just to satisfy a checker, and a rarely used one. Zbyszek > > diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c > index 3fbe680..8e5be87 100644 > --- a/src/core/load-fragment.c > +++ b/src/core/load-fragment.c > @@ -3586,7 +3586,7 @@ int unit_load_fragment(Unit *u) { > return r; > > /* Try to find an alias we can load this with */ > -if (u->load_state == UNIT_STUB) > +if (u->load_state == UNIT_STUB) { > SET_FOREACH(t, u->names, i) { > > if (t == u->id) > @@ -3599,6 +3599,7 @@ int unit_load_fragment(Unit *u) { > if (u->load_state != UNIT_STUB) > break; > } > +} > > /* And now, try looking for it under the suggested (originally > linked) path */ > if (u->load_state == UNIT_STUB && u->fragment_path) { > @@ -3628,7 +3629,7 @@ int unit_load_fragment(Unit *u) { > if (r < 0) > return r; > > -if (u->load_state == UNIT_STUB) > +if (u->load_state == UNIT_STUB) { > SET_FOREACH(t, u->names, i) { > _cleanup_free_ char *z = NULL; > > @@ -3646,6 +3647,7 @@ int unit_load_fragment(Unit *u) { > if (u->load_state != UNIT_STUB) > break; > } > +} > } > > return 0; > diff --git a/src/journal-remote/journal-remote.c > b/src/journal-remote/journal-remote.c > index 6ec5ad2..5050616 100644 > --- a/src/journal-remote/journal-remote.c > +++ b/src/journal-remote/journal-remote.c > @@ -1469,13 +1469,13 @@ static int setup_gnutls_logger(char **categories) { > > gnutls_global_set_log_function(log_func_gnutls); > > -if (categories) > +if (categories) { > STRV_FOREACH(cat, categories) { > r = log_enable_gnutls_category(*cat); > if (r < 0) > return r; > } > -else > +} else > log_reset_gnutls_level(); > } > #endif > > ___ > systemd-commits mailing list > systemd-comm...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-commits ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On Fri, Dec 12, 2014 at 04:07:23PM +0100, Lennart Poettering wrote: > On Fri, 12.12.14 09:07, Rauta, Alin (alin.ra...@intel.com) wrote: > > > What do you think about the following transformations: > > > > [FDBEntry] => [FDBNeigh] > > We try to avoid acronyms and abbreviations unless they are very widely > established. Hence I am not convinced "Neigh" is something we should > use. > > Given that "fdb" and "entry" are commonly used I think [FDBEntry] > would be fine. I don't think it's widely established. E.g. compared to "VLAN", it certainly isn't. "FDB" is also pretty much non-googlable. "ForwardingDatabase" is imho much nicer and easier to search for. Also, it's not like you type those things by hand every day, so saving a few characters should not be a consideration. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network
On Fri, Dec 12, 2014 at 08:11:54PM +0100, Lennart Poettering wrote: > On Fri, 05.12.14 15:54, Karel Zak (k...@redhat.com) wrote: > > I guess it's enough to add the 'fd' to systmed sd_event_add_io() and > > call mnt_table_parse_mtab() when a change is detected. (As already > > implemeted in the original Chris' patch.) > > Karel, if I got this right, then the new monitor stuff will only wrap > inotify on utab, right? Right. > I think it would be useful if it would also > abstract notifications via /proc/self/mountinfo in it. To make the I have had plan to add mnt_monitor_kernel_get_fd(). > interface easy for this and to be able to just hand out a single fd, > this would mean creating an epoll fd inside the lib, then adding the > inotify fd for utab to it, and then on top the EPOLLPRI watch on > /proc/self/mountinfo. > > This way apps would get the full set of notifications via your > library, without knowing what's going on underneath, and userspace > notifications and kernel notifications would come the same way. I don't want provide only high-level abstraction, sometimes it's useful for developers to have access to low-level things (for example sometimes utab monitoring is unnecessary overkill). It's also possible that in future there will be more things to monitor (mountinfo in another namespaces, FS specific things, ...etc). Maybe the API should be extended to something like: mnt_monitor_enable_userspace(mn, TRUE); mnt_monitor_enable_kernel(mn, TRUE); fd = mnt_monitor_get_fd(mn); where 'fd' is the top level file descriptor to monitor all enabled things. Hmm... OK, next week ;-) Karel -- Karel Zak http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build error with 218 - undefined reference to `__start_BUS_ERROR_MAP'
On Fri, Dec 12, 2014 at 4:46 PM, Lennart Poettering wrote: > On Fri, 12.12.14 10:10, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > >> > >> > https://sourceware.org/bugzilla/show_bug.cgi?id=11133 >> > >> > But that's 4y old... Or is your toolchain that old? >> >> Shouldn't be: >> >> mipsisa32r2el-axis-linux-gnu-gcc --version >> mipsisa32r2el-axis-linux-gnu-gcc (GCC 4.7.2 Axis release R24/1.24) >> 4.7.2 20120820 (prerelease) [gcc-4_7-branch revision 190527] > > That's the gcc version. And what binutils version is this? mipsisa32r2el-axis-linux-gnu-ld --version GNU ld (GNU Binutils) 2.24.51.20131126 Copyright 2013 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. I will double check things with our compiler tools group. > > 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 v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network
On Fri, 05.12.14 15:54, Karel Zak (k...@redhat.com) wrote: > I have added struct libmnt_monitor to make this new interface easy to > extend and usable for more resources (I'll probably also add mountinfo > fd for findmnt(8), but this is irrelevant for systemd;-) > > All you need is: > > mn = mnt_new_monitor(); > fd = mnt_monitor_userspace_get_fd(mn, NULL);/* utab monitor fd */ > > mnt_monitor_get_events(mn, fd, &ev.events); /* EPOLLIN ... */ > > efd = epoll_create1(EPOLL_CLOEXEC); > epoll_ctl(efd, EPOLL_CTL_ADD, fd, &ev); > > > n = epoll_wait(efd, events, 1, -1); > id (n == 1 && mnt_monitor_is_changed(mn, fd) == 1) > printf("%s: change detected\n", mnt_monitor_get_filename(mn, > fd)); > > > mnt_unref_monitor(mn); > close(efd); > > > I guess it's enough to add the 'fd' to systmed sd_event_add_io() and > call mnt_table_parse_mtab() when a change is detected. (As already > implemeted in the original Chris' patch.) Karel, if I got this right, then the new monitor stuff will only wrap inotify on utab, right? I think it would be useful if it would also abstract notifications via /proc/self/mountinfo in it. To make the interface easy for this and to be able to just hand out a single fd, this would mean creating an epoll fd inside the lib, then adding the inotify fd for utab to it, and then on top the EPOLLPRI watch on /proc/self/mountinfo. This way apps would get the full set of notifications via your library, without knowing what's going on underneath, and userspace notifications and kernel notifications would come the same way. Does this make sense? 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] blkid: Warn when rejecting a superblock with a bad csum
Should the line: PKG_CHECK_MODULES(BLKID, [ blkid >= 2.24 ], instead read PKG_CHECK_MODULES(BLKID, [ blkid >= 2.25 ], instead since the commit message appears to mandate 2.25 not 2.24? Regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
For now I'm concerned with the FDB entries. They are in the .network files following the logic of [Address] & [Route] sections. /Alin -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of "Jóhann B. Guðmundsson" Sent: Friday, December 12, 2014 4:41 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add FDB support On 12/12/2014 04:12 PM, Rauta, Alin wrote: > Hi, > > [BrigdeFDB] can be also fine. It's just that [BridgeFDB] makes you think at > the entire forwarding database table and you are actually defining only one > entry. > [BridgeFDBEntry] makes you think at just one entry in that table. Hmm So it can grow quite large with multiple entries along with all the other bridging features. At this point in time I'm actually wondering if it would not be better to introduce type .bridge networkd file to cover all current and future bridge features ( for example you probably want to be able to define that 802.1ad tag in an [Bridge] section as well right? ) as opposed to be cluttering the .network file with all of those options. Do you have any number of how many various type bridge entries will need to be supported by networkd in the long run? JBG ___ 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] Add FDB support
On 12/12/2014 04:12 PM, Rauta, Alin wrote: Hi, [BrigdeFDB] can be also fine. It's just that [BridgeFDB] makes you think at the entire forwarding database table and you are actually defining only one entry. [BridgeFDBEntry] makes you think at just one entry in that table. Hmm So it can grow quite large with multiple entries along with all the other bridging features. At this point in time I'm actually wondering if it would not be better to introduce type .bridge networkd file to cover all current and future bridge features ( for example you probably want to be able to define that 802.1ad tag in an [Bridge] section as well right? ) as opposed to be cluttering the .network file with all of those options. Do you have any number of how many various type bridge entries will need to be supported by networkd in the long run? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
Hi, [BrigdeFDB] can be also fine. It's just that [BridgeFDB] makes you think at the entire forwarding database table and you are actually defining only one entry. [BridgeFDBEntry] makes you think at just one entry in that table. /Alin -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Matthias Urlichs Sent: Friday, December 12, 2014 3:32 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add FDB support Hi, "Jóhann B. Guðmundsson": > After I explained it to them they said why not just call it [BridgeFDB] ... > +1 -- -- Matthias Urlichs ___ 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] Add FDB support
> If I get this right "fdb" only makes sense in a bridge context, correct? > Maybe [BridgeFDBEntry] instead? Yes, the FDB table is used by a Layer 2 device (switch/bridge), but an ordinary interface also has a FDB table. [BridgeFDBEntry] seems also fine. > I mean, if networkd would simply flush the fdb of bridge devices > unconditionally when it initializes that interface, would that be a problem? It's fine to flush the table unconditionally, but this means the operation will be done for all kind of ports even if you are on a switch or not. There may be an issue when running networkd and a port state is UP (for example when running networkd from command line), because during the UP operation, linux kernel adds some multicast FDB entries: Ex: bridge fdb show dev em1 01:00:5e:00:00:01 self permanent 33:33:ff:8f:e7:4b self permanent Without "FDBControlled/FDBCleanTable" then we clear the above mentioned multicast FDB entries and no one configures them again. A down - up operation in the code would help but I guess it's not acceptable. /Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Friday, December 12, 2014 3:07 PM To: Rauta, Alin Cc: 'systemd-devel@lists.freedesktop.org'; Kinsella, Ray Subject: Re: [systemd-devel] [PATCH] Add FDB support On Fri, 12.12.14 09:07, Rauta, Alin (alin.ra...@intel.com) wrote: > What do you think about the following transformations: > > [FDBEntry] => [FDBNeigh] We try to avoid acronyms and abbreviations unless they are very widely established. Hence I am not convinced "Neigh" is something we should use. Given that "fdb" and "entry" are commonly used I think [FDBEntry] would be fine. If I get this right "fdb" only makes sense in a bridge context, correct? Maybe [BridgeFDBEntry] instead? > FDBControlled=> FDBCleanTable > VLAN => VLANId > > ? > > When FDBCleanTable is set to yes, networkd will clean the existing FDB > entries for current port and FDBCleanTable will have no impact on [FDBNeigh] > sections Hmm, networkd takes ownership of the network interfaces it is configured to manage, hence I am wondering whether the flushing of the FDB should not be the implied logic when it takes possession of an interface? Is there a good usecase why one would *not* want this? I mean, if networkd would simply flush the fdb of bridge devices unconditionally when it initializes that interface, would that be a problem? 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] Build error with 218 - undefined reference to `__start_BUS_ERROR_MAP'
On Fri, 12.12.14 10:10, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=11133 > > > > But that's 4y old... Or is your toolchain that old? > > Shouldn't be: > > mipsisa32r2el-axis-linux-gnu-gcc --version > mipsisa32r2el-axis-linux-gnu-gcc (GCC 4.7.2 Axis release R24/1.24) > 4.7.2 20120820 (prerelease) [gcc-4_7-branch revision 190527] That's the gcc version. And what binutils version is this? 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] Add FDB support
Hi, "Jóhann B. Guðmundsson": > After I explained it to them they said why not just call it [BridgeFDB] ... > +1 -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On 12/12/2014 03:12 PM, "Jóhann B. Guðmundsson" wrote: On 12/12/2014 03:07 PM, Lennart Poettering wrote: Given that "fdb" and "entry" are commonly used I think [FDBEntry] would be fine. It exist there in the first place makes it an "entry" so what's wrong with just calling this entry [FDB]? Ignore that I asked for an opinion from the network guys and they went like what does FDB stand for? After I explained it to them they said why not just call it [BridgeFDB] ... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On 12/12/2014 03:07 PM, Lennart Poettering wrote: Given that "fdb" and "entry" are commonly used I think [FDBEntry] would be fine. It exist there in the first place makes it an "entry" so what's wrong with just calling this entry [FDB]? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add FDB support
On Fri, 12.12.14 09:07, Rauta, Alin (alin.ra...@intel.com) wrote: > What do you think about the following transformations: > > [FDBEntry] => [FDBNeigh] We try to avoid acronyms and abbreviations unless they are very widely established. Hence I am not convinced "Neigh" is something we should use. Given that "fdb" and "entry" are commonly used I think [FDBEntry] would be fine. If I get this right "fdb" only makes sense in a bridge context, correct? Maybe [BridgeFDBEntry] instead? > FDBControlled=> FDBCleanTable > VLAN => VLANId > > ? > > When FDBCleanTable is set to yes, networkd will clean the existing FDB > entries for current port and FDBCleanTable will have no impact on [FDBNeigh] > sections Hmm, networkd takes ownership of the network interfaces it is configured to manage, hence I am wondering whether the flushing of the FDB should not be the implied logic when it takes possession of an interface? Is there a good usecase why one would *not* want this? I mean, if networkd would simply flush the fdb of bridge devices unconditionally when it initializes that interface, would that be a problem? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fail to reset-failed as user
Hi, Today I had one unit in failed state, and after taking care of things I wanted to simply reset its state (to inactive) w/out having to start it. Looking up the man page, I see there's a command reset-failed for this exact purpose, awesome. So I go: % systemctl reset-failed backups2.service Failed to reset failed state of unit backups2.service: No such device or address I was nicely asked to authenticate, but then it failed stating the unit doesn't exist or something (not sure what the error message refers to)? Now of course said unit does exist: % systemctl is-failed backups2.service failed And I could eventually do it, as root: % sudo systemctl reset-failed backups2.service This worked fine and is probably what I would have done had my fingers not slipped (sc instead of ssc, aliases for `systemctl` and `sudo systemctl` resp.), but I'm not sure what I missed: since I was properly authenticated, shouldn't the systemctl call also have worked? FYI here's what shows up in the journal, confirming the auth: Dec 12 15:40:00 arch.local polkitd[670]: Operator of unix-session:c3 successfully authenticated as unix-user:jjacky to gain TEMPORARY authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.259 [systemctl reset-failed backups2.service] (owned by unix-user:jjacky) What am I missing/misunderstanding? (or is this a bug?) Thanks, -j ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unit files on another partition
hi, Our / partitions are on a squashfs media, which means that unit files are read-only. There is a partition for read-write content (Scratchable), and I'm wondering if it would be possible to add unit-files there and have the boot order cope with this correctly? How should this be set up -properly- (of course I can just insert a unit early on depending on the mounting of the RW-area and have everything depend on this, but I'm not sure that's the -right- solution. ) //D.S. -- 8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC 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] [ANNOUNCE] systemd v218
On 12/12/2014 02:57 PM, Matthias Urlichs wrote: Hi, Colin Guthrie: What's the argument for including /usr/local in all this stuff? Feels wrong to me. +ME_TOO. /usr/local frequently has wider permissions than reasonable for something that can affect system startup. I can think of one argument in favor of this -- you can modify the system default that way, without touching /etc, so this would add local modifications to an image which you then use for system initialization. However, you can do the same thing by adding appropriate *.conf files to /usr/lib/systemd/**. I'm jumping on this bandwagon of agreements as well. Supporting this makes no sense... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
Hi, Colin Guthrie: > What's the argument for including /usr/local in all this stuff? Feels > wrong to me. > +ME_TOO. /usr/local frequently has wider permissions than reasonable for something that can affect system startup. I can think of one argument in favor of this -- you can modify the system default that way, without touching /etc, so this would add local modifications to an image which you then use for system initialization. However, you can do the same thing by adding appropriate *.conf files to /usr/lib/systemd/**. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Something is removing links from my *.wants/ directory
Adam Papai wrote on 11/12/14 09:17: > Why and what is removing my files from the target directories? Those are > required to run the lxc-container properly otherwise it'll boot up in a > dergaded state, without ssh and iptables forwarding and so on. > > What did I miss? Is it something change between 215 - 217? I debugged it > with strace and lxc-start does nothing with those files. > > Any help is appreciated! Just as a random guess, systemctl preset-all is perhaps now run when /etc/ is detected as empty as part of the first-boot stuff to initialise /etc properly... perhaps this is to blame? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
Lennart Poettering wrote on 11/12/14 00:16: > * All systemd programs that read standalone configuration > files in /etc now also support a corresponding series of > .conf.d configuration directories in /etc/, /run/, > /usr/local/lib/, /usr/lib/, and (if configured with > --enable-split-usr) /lib/. In particular, the following > configuration files now have corresponding configuration > directories: system.conf user.conf, logind.conf, > journald.conf, sleep.conf, bootchart.conf, coredump.conf, > resolved.conf, timesyncd.conf, journal-remote.conf, and > journal-upload.conf. Note that distributions should use the > configuration directories in /usr/lib/; the directories in > /etc/ are reserved for the system administrator. Hmmm, at what point is /usr/local/lib/systemd/journald.conf.d/foo.conf read? Does the journal start only after all local filesystems are mounted, I don't see anything that ensures this in the .service or .socket files for it (same applies to other tools, but journal is probably most at risk because it's started early with DefaultDependencies=no) It feels very, very odd that /usr/local is being parsed at all here when the --prefix arg does not include it. I mean this kinda conflicts with users doing their own compiles with --prefix=/usr/local and installing stuff there... If the were experimenting, but ultimately didn't want to use it, it seems odd to me that the actual packaged version of system would read these files. What's the argument for including /usr/local in all this stuff? Feels wrong to me. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] libsystemd-network tests failing in mock
Tom Gundersen writes: > On Thu, Dec 11, 2014 at 9:14 AM, Jan Synáček wrote: >> test-dhcp-{client,server} are failing in mock: >> >> FAIL: test-dhcp-client >> == >> Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:138, >> function sd_dhcp_client_set_request_option(). Ignoring. >> Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:169, >> function sd_dhcp_client_set_request_address(). Ignoring. >> Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:182, >> function sd_dhcp_client_set_index(). Ignoring. >> Assertion 'interface_index > 0' failed at >> ../src/libsystemd-network/sd-dhcp-client.c:185, function >> sd_dhcp_client_set_index(). Ignoring. >> Assertion 'interface_index > 0' failed at >> ../src/libsystemd-network/sd-dhcp-client.c:185, function >> sd_dhcp_client_set_index(). Ignoring. >> Assertion 'interface_index > 0' failed at >> ../src/libsystemd-network/sd-dhcp-client.c:185, function >> sd_dhcp_client_set_index(). Ignoring. >> DHCP CLIENT (0x0): FREE >> DHCP CLIENT (0xbe31128b): STARTED on ifindex 42 >> DHCP CLIENT (0xbe31128b): DISCOVER >> DHCP CLIENT (0xbe31128b): STOPPED >> DHCP CLIENT (0x0): FREE >> DHCP CLIENT (0x45d3fd67): STARTED on ifindex 42 >> DHCP CLIENT (0x45d3fd67): DISCOVER >> DHCP CLIENT (0x45d3fd67): OFFER >> DHCP CLIENT (0x45d3fd67): REQUEST (requesting) >> DHCP CLIENT (0x45d3fd67): ACK >> DHCP CLIENT (0x45d3fd67): lease expires in 9min 57.698157s >> DHCP CLIENT (0x45d3fd67): T2 expires in 8min 42.895614s >> DHCP CLIENT (0x45d3fd67): T1 expires in 5min 101.292ms >> DHCP CLIENT (0x45d3fd67): STOPPED: Operation not permitted > > > This is really odd. I cannot reproduce, and looking at the code I > cannot figure out how this could ever happen. I pushed a bit of extra > logging just now, but even so I really don't see it. > > Any chance you can reproduce this locally and either let me know how, > or go step through it with gdb and see where the EPERM originates? Assuming that you run Fedora, you can patch the current specfile that is in rawhide with the patch in [1]. Then, just execute "fedpkg mockbuild". I tried to manually make the test fail directly inside the mock buildroot, but couldn't make it work. After patching the spec, you can create an srpm with "fedpkg srpm" and then use mock direcly like so: $ mock -r fedora-rawhide-x86_64 --no-cleanup --no-cleanup-after You'll then have the root and the results in /var/lib/mock/fedora-rawhide-x86_64/result. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1076119 Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] blkid: Warn when rejecting a superblock with a bad csum
Bump libblkid requirement from 2.20 to 2.24. util-linux 2.25 is actually required since fdbbad981cc5da8bb4ed7e9b6646e7a114745ec5 --- configure.ac | 2 +- src/udev/udev-builtin-blkid.c | 13 - 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 9218ed3..453f5de 100644 --- a/configure.ac +++ b/configure.ac @@ -430,11 +430,11 @@ AM_CONDITIONAL(HAVE_XKBCOMMON, [test "$have_xkbcommon" = "yes"]) # -- have_blkid=no AC_ARG_ENABLE(blkid, AS_HELP_STRING([--disable-blkid], [disable blkid support])) if test "x$enable_blkid" != "xno"; then -PKG_CHECK_MODULES(BLKID, [ blkid >= 2.20 ], +PKG_CHECK_MODULES(BLKID, [ blkid >= 2.24 ], [AC_DEFINE(HAVE_BLKID, 1, [Define if blkid is available]) have_blkid=yes], have_blkid=no) if test "x$have_blkid" = xno -a "x$enable_blkid" = xyes; then AC_MSG_ERROR([*** blkid support requested but libraries not found]) fi fi diff --git a/src/udev/udev-builtin-blkid.c b/src/udev/udev-builtin-blkid.c index 810f27d..83bd8c4 100644 --- a/src/udev/udev-builtin-blkid.c +++ b/src/udev/udev-builtin-blkid.c @@ -219,10 +219,11 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t bool noraid = false; _cleanup_close_ int fd = -1; blkid_probe pr; const char *data; const char *name; +const char *prtype = NULL; int nvals; int i; int err = 0; bool is_gpt = false; @@ -254,11 +255,12 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t return EXIT_FAILURE; blkid_probe_set_superblocks_flags(pr, BLKID_SUBLKS_LABEL | BLKID_SUBLKS_UUID | BLKID_SUBLKS_TYPE | BLKID_SUBLKS_SECTYPE | -BLKID_SUBLKS_USAGE | BLKID_SUBLKS_VERSION); +BLKID_SUBLKS_USAGE | BLKID_SUBLKS_VERSION | +BLKID_SUBLKS_BADCSUM); if (noraid) blkid_probe_filter_superblocks_usage(pr, BLKID_FLTR_NOTIN, BLKID_USAGE_RAID); fd = open(udev_device_get_devnode(dev), O_RDONLY|O_CLOEXEC); @@ -276,10 +278,19 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t noraid ? "no" : "", offset); err = probe_superblocks(pr); if (err < 0) goto out; +if (blkid_probe_has_value(pr, "SBBADCSUM")) { +if (!blkid_probe_lookup_value(pr, "TYPE", &prtype, NULL)) +log_warning("incorrect %s checksum on %s", +prtype, udev_device_get_devnode(dev)); +else +log_warning("incorrect checksum on %s", +udev_device_get_devnode(dev)); +goto out; +} /* If we are a partition then our parent passed on the root * partition UUID to us */ root_partition = udev_device_get_property_value(dev, "ID_PART_GPT_AUTO_ROOT_UUID"); -- 2.1.2.457.g0cd6422 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build error with 218 - undefined reference to `__start_BUS_ERROR_MAP'
In case someone has an idea, here is the full linker command: /bin/sh ./libtool --tag=CC --mode=link mipsisa32r2el-axis-linux-gnu-gcc -isystem /build/target/mipsisa32r2el-axis-linux-gnu/include -isystem /build/target/mipsisa32r2el-axis-linux-gnu/usr/include -std=gnu99 -pipe -Wall -Wextra -Wno-inline -Wundef -Wformat=2 -Wformat-security -Wformat-nonliteral -Wlogical-op -Wsign-compare -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Werror=overflow -Wnested-externs -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden -ffunction-sections -fdata-sections -fstack-protector -fPIE --param=ssp-buffer-size=4 -flto -ffat-lto-objects -Wall -Wshadow -O2 -g3 -D_FORTIFY_SOURCE=2 -fstack-protector -Wl,--as-needed -Wl,--no-undefined -Wl,--gc-sections -Wl,-z,relro -Wl,-z,now -pie -Wl,-fuse-ld=gold -module -export-dynamic -avoid-version -shared -shrext .so.2 -Wl,--version-script=/build/apps/systemd/systemd/src/nss-resolve/nss-resolve.sym -L/build/target/mipsisa32r2el-axis-linux-gnu/lib -L/build/target/mipsisa32r2el-axis-linux-gnu/usr/lib -Wl,-rpath-link,/build/target/mipsisa32r2el-axis-linux-gnu/lib:/build/target/mipsisa32r2el-axis-linux-gnu/usr/lib -o libnss_resolve.la -rpath /usr/lib src/nss-resolve/nss-resolve.lo libsystemd-shared.la libsystemd-internal.la -lrt -ldl On Fri, Dec 12, 2014 at 10:10 AM, Umut Tezduyar Lindskog wrote: > On Fri, Dec 12, 2014 at 12:24 AM, Lennart Poettering > wrote: >> On Thu, 11.12.14 23:01, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: >> >>> Trying to build 218 but I am getting undefined reference error. The >>> source code of bus-error.c mentions that gcc magically maps these >>> variables but not for me. >>> >>> What is doing the mapping? __attribute__ ((__section__("BUS_ERROR_MAP"))) ? >>> >>> Could it be that mentioned "gcc magic" is not supported on cross compiling? >>> >>> Also, why do we need to use elf section instead of iterating over >>> bus_standard_errors[]? >> >> The idea is that any .c file linked into a binary can define >> additional maps, and we collect them all simply by iterating through >> __start_BUS_ERROR_MAP to __stop_BUS_ERROR_MAP. >> >> The __start_XYZ/__stop_XYZ magic is pretty old ld/gold stuff, support >> since a long time. >> >> Is there something fishy with your toolchain? Any particular build >> time options you turned on or off? Some really old ld >> versions would end up dropping these sections a bit too eagerly: > > Maybe. I will ask this internally too. > >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=11133 >> >> But that's 4y old... Or is your toolchain that old? > > Shouldn't be: > > mipsisa32r2el-axis-linux-gnu-gcc --version > mipsisa32r2el-axis-linux-gnu-gcc (GCC 4.7.2 Axis release R24/1.24) > 4.7.2 20120820 (prerelease) [gcc-4_7-branch revision 190527] > > >> >>> CCLD libnss_resolve.la >>> libsystemd_shared_la-hashmap.o (symbol from plugin): warning: memset >>> used with constant zero length parameter; this could be due to >>> transposed parameters >>> /tmp/ccHr0vVt.ltrans13.ltrans.o: In function >>> `bus_error_name_to_errno.14134': >>> ccHr0vVt.ltrans13.o:(.text+0x7b0): undefined reference to >>> `__start_BUS_ERROR_MAP' >>> ccHr0vVt.ltrans13.o:(.text+0x7b4): undefined reference to >>> `__stop_BUS_ERROR_MAP' >>> collect2: error: ld returned 1 exit status >>> >>> Umut >>> ___ >>> systemd-devel mailing list >>> systemd-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> >> >> Lennart >> >> -- >> Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build error with 218 - undefined reference to `__start_BUS_ERROR_MAP'
On Fri, Dec 12, 2014 at 12:24 AM, Lennart Poettering wrote: > On Thu, 11.12.14 23:01, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > >> Trying to build 218 but I am getting undefined reference error. The >> source code of bus-error.c mentions that gcc magically maps these >> variables but not for me. >> >> What is doing the mapping? __attribute__ ((__section__("BUS_ERROR_MAP"))) ? >> >> Could it be that mentioned "gcc magic" is not supported on cross compiling? >> >> Also, why do we need to use elf section instead of iterating over >> bus_standard_errors[]? > > The idea is that any .c file linked into a binary can define > additional maps, and we collect them all simply by iterating through > __start_BUS_ERROR_MAP to __stop_BUS_ERROR_MAP. > > The __start_XYZ/__stop_XYZ magic is pretty old ld/gold stuff, support > since a long time. > > Is there something fishy with your toolchain? Any particular build > time options you turned on or off? Some really old ld > versions would end up dropping these sections a bit too eagerly: Maybe. I will ask this internally too. > > https://sourceware.org/bugzilla/show_bug.cgi?id=11133 > > But that's 4y old... Or is your toolchain that old? Shouldn't be: mipsisa32r2el-axis-linux-gnu-gcc --version mipsisa32r2el-axis-linux-gnu-gcc (GCC 4.7.2 Axis release R24/1.24) 4.7.2 20120820 (prerelease) [gcc-4_7-branch revision 190527] > >> CCLD libnss_resolve.la >> libsystemd_shared_la-hashmap.o (symbol from plugin): warning: memset >> used with constant zero length parameter; this could be due to >> transposed parameters >> /tmp/ccHr0vVt.ltrans13.ltrans.o: In function `bus_error_name_to_errno.14134': >> ccHr0vVt.ltrans13.o:(.text+0x7b0): undefined reference to >> `__start_BUS_ERROR_MAP' >> ccHr0vVt.ltrans13.o:(.text+0x7b4): undefined reference to >> `__stop_BUS_ERROR_MAP' >> collect2: error: ld returned 1 exit status >> >> Umut >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > Lennart > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build error with 218 - undefined reference to `__start_BUS_ERROR_MAP'
Hi, On Fri, Dec 12, 2014 at 7:56 AM, Matthias Urlichs wrote: > Hi, > > Lennart: >> >> The idea is that any .c file linked into a binary can define >> additional maps, and we collect them all simply by iterating through >> __start_BUS_ERROR_MAP to __stop_BUS_ERROR_MAP. >> > Unless there are none of these entries. > > Umut: Does the cross compiling somehow not include any > data that are in section BUS_ERROR_MAP? This doesn't seem to be the case. I looked at the libsystemd_la-bus-error.o and I have the BUS_ERROR_MAP section with size 0x118 which matches with source code 32bit mips [1]. The __start_BUS_ERROR_MAP, __stop_BUS_ERROR_MAP symbols are in the object file too as unresolved [2]. Somehow static linker doesn't resolve the symbols to section begin/end. Any other suggestions? [1] - https://drive.google.com/open?id=0B_uiALgWpGXtSVpUR3pwcWNodGc&authuser=0 [2] - https://drive.google.com/open?id=0B_uiALgWpGXtNGFKSlR4VjN4MGM&authuser=0 Umut > > If that's actually intended, this should fix it: > > char dummy_bus_error_map[0] __attribute__ ((__section__("BUS_ERROR_MAP"))); > > -- > -- Matthias Urlichs > > ___ > 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] Add FDB support
What do you think about the following transformations: [FDBEntry] => [FDBNeigh] FDBControlled=> FDBCleanTable VLAN => VLANId ? When FDBCleanTable is set to yes, networkd will clean the existing FDB entries for current port and FDBCleanTable will have no impact on [FDBNeigh] sections /Alin -Original Message- From: Rauta, Alin Sent: Thursday, December 11, 2014 4:58 PM To: Lennart Poettering Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray Subject: RE: [systemd-devel] [PATCH] Add FDB support Hi Lennart, Thanks for your quick response. Regarding the naming "FDBEntry". My inspiration was the bridge tool command. To add an entry using bridge command: "bridge fdb add 44:44:12:34:56:73 dev em1 vlan 10 " If "FDBControlled" is no (default value) then the forwarding database table for current port is not touched even if we have entries in the [FDBEntry] section of the file. The reason behind introducing "FDBControlled" is that we want to have the table cleared even if we don't want to add entries. So, if FDBControlled is set to yes, networkd clears the existing entries (if any) and adds those specified in the FDBEntry section(if any). Do you have any other suggestion for [FDBEntry] ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, December 11, 2014 4:16 PM To: Rauta, Alin Cc: systemd-devel@lists.freedesktop.org; Kinsella, Ray Subject: Re: [systemd-devel] [PATCH] Add FDB support On Thu, 11.12.14 08:07, Alin Rauta (alin.ra...@intel.com) wrote: > Hi, > > I've added support for handling the forwarding database table for a port. > FDB entries can be configured statically through the ".network" files. > > To resume, > - I've added a new boolean for the main network structure, named > "FDBControlled" which is read from the .network file and defaults to false. > - I've added a new section "FDBEntry" accepting 2 key-value pairs: > -MACAddress (mandatory) > -VLAN (optional) > > When FDBControlled is set to "yes" in the network section, networkd: > - gets the FDB entries for current port; > - clears them > - configures those specified in the [FDBEntry] section. > > Configuration example: > > [Network] > DHCP=v4 > FDBControlled=yes > > [FDBEntry] > MACAddress=44:44:12:34:56:71 > VLAN=9 > > [FDBEntry] > MACAddress=44:44:12:34:56:72 > VLAN=10 Hmm, quick thoughts regarding the naming: can we find a better name than [FDBEntry] for this? At least I cannot really make much sense of this. Could you improve the man page a bit, explaining what "fdb" actually is? Currently VLANs are configured in a [VLAN] section, with an Id= setting to configure the id. Maybe following this naming the setting you introduce above should be called VLANId? What happens if FDBControlled is no, but still FDBEntrys specified? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel