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
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 lenn...@poettering.net 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'
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 u...@tezduyar.com wrote: On Fri, Dec 12, 2014 at 12:24 AM, Lennart Poettering lenn...@poettering.net 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
[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] 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
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] [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
[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
[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
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] [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 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
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] 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
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] [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
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
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] 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 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] Build error with 218 - undefined reference to `__start_BUS_ERROR_MAP'
On Fri, Dec 12, 2014 at 4:46 PM, Lennart Poettering lenn...@poettering.net 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, 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 k...@redhat.com http://karelzak.blogspot.com ___ 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] 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 zbys...@in.waw.pl 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] 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 gm...@colin.guthr.ie 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
[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] [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
