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
