[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <910194713.25283.1571260614731.JavaMail.zimbra@nod.at>
Date: Wed, 16 Oct 2019 23:16:54 +0200 (CEST)
From: Richard Weinberger <richard@....at>
To: Roopa Prabhu <roopa@...ulusnetworks.com>
Cc: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
Richard Weinberger <richard.weinberger@...il.com>,
netdev <netdev@...r.kernel.org>,
bridge@...ts.linux-foundation.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: Bridge port userspace events broken?
Roopa, Nikolay,
----- Ursprüngliche Mail -----
> +1, this can be fixed....but in general all new bridge and link
> attributes have better support with netlink.
> In this case its IFLA_BRPORT_GROUP_FWD_MASK link attribute available
> via ip monitor or bridge monitor.
> you probably cannot use it with udev today.
>
> For the future, I think having udev listen to netlink link and devlink
> events would make sense (Not sure if anybody is working on it).
> AFAIK the sysfs uevent mechanism for link attributes don't receive
> the required attention and testing like the equivalent netlink events.
I understand that netlink works best for you but sysfs notifications are still
useful.
Please let me explain my use case a little bit more.
The application I work on operates on network interfaces, in this case the
interface happens to be a bridge.
systemd-networkd sets up the bridge as soon all slave interfaces emerge.
Therefore the systemd service file of the application depends on the bridge.
i.e.
Requires=sys-subsystem-net-devices-br0.device
In one specific setup the bridge needs to forward more than usual and
group_fwd_mask needs to be altered. Sadly this is nothing systemd-networkd
can do right now, so I added the following line to the service file of
the application:
ExecStartPre=/bin/bash -c "echo 0xfffd > /sys/class/net/eth0/brport/group_fwd_mask"
Here comes the problem, the unit is activated as soon br0 is created but
at this time eth0 is sometimes not yet a slave or br0. It takes some time.
So I need a way to model this dependency in a systemd environment.
A common approach to do so is setting up an udev rule which set a systemd notify
as soon a specific sysfs file arrives.
Teaching the application to listen for bridge specific netlink messages is
another possible approach but seems overkill to me.
Or maybe there is some nice wrapper/helper?
It would be nice to have sysfs notifications for bridge devices too.
I can understand that not everyone likes this approach but this is the way
how *many* systems out there work these day. Actually almost any (embedded)
system with systemd.
Thanks,
//richard
Powered by blists - more mailing lists