Thu, Mar 28, 2019 at 07:41:43AM CET, mkubecek@suse.cz wrote:

On Wed, Mar 27, 2019 at 07:14:43PM -0700, Florian Fainelli wrote:

quoted

On 3/27/2019 7:14 AM, Michal Kubecek wrote:

quoted

On Wed, Mar 27, 2019 at 02:04:28PM +0100, Jiri Pirko wrote:

quoted

Mon, Mar 25, 2019 at 06:08:21PM CET, mkubecek@suse.cz wrote:

quoted

Three types of netlink notifications are introduced:

 - ETHA_EVENT_NEWDEV to notify about newly registered network devices
 - ETHA_EVENT_DELDEV to notify about unregistered network devices
 - ETHA_EVENT_RENAMEDEV to notify about renamed network device

The notifications are triggered by NETDEV_REGISTER, NETDEV_UNREGISTER and
NETDEV_CHANGENAME notifiers.

These notifications are intended for applications and daemons monitoring
ethtool events to allow updating the list of existing devices without
having to open another socket for rtnetlink.

Wait. You duplicate events that are already going out through RTNETLINK.
App should open RTNETLINK in order to get those. Other apps are doing
that too. I don't think that duplications like this are desirable :/

Is there a way to filter or at least recognize these events when using
rtnetlink? I couldn't find any. The only way seems to be getting every
RTM_NEWLINK message (there can be quite a lot of those), always perform
the lookup in my device list and recognize what happened - only to
almost always find that nothing interesting. It is possible, sure, but
I would really like to avoid it.

I am afraid you are right about this, would adding a filtering
capability specifically for this in rtnetlink be a better route?

Maybe we could add new IFLA_EVENT_* values and use IFLA_EVENT to mark
RTM_NEWLINK messages announcing "new device" and "device rename". That
way, monitoring application would still need to parse all RTM_NEWLINK
messages but it would be able to recognize which announce a change in
device list without a lookup in its structures.

Hmm, that sounds good.

Michal