Re: [PATCH] (1/5) replay netdev notifier events on registration

["David S. Miller" <davem@redhat.com>]

On Thu, 15 Jan 2004 10:16:17 -0800
Stephen Hemminger <shemminger@osdl.org> wrote:

> On Thu, 15 Jan 2004 00:42:55 -0800
> "David S. Miller" <davem@redhat.com> wrote:
> 
> > Ok, I have an idea, consider this.  We add a netdev->notifier()
> > method.  We create a new routine to net/core/dev.c:
> > 
> > static void run_netdev_notifiers(int event, struct net_device *dev)
> > {
> > 	notifier_call_chain(&netdev_chain, event, dev);
> > 
> > 	if (dev->notifier)
> > 		dev->notifier(dev, event);
> > }
> > 
> > Then replace all the notifier_call_chain(&netdev_chain, ...) calls
> > in net/core/dev.c with invocations of run_netdev_notifiers().
> > 
> > I believe we can (and thus should) add an ASSERT_RTNL() to this new
> > run_netdev_notifiers() functions, although I'm not %100 sure.
> > 
> > What do you think Stephen?
> 
> Feeling stupid this morning, how wold this help?  Would device set
> dev->notifier and not register for other notifications?

That's correct.  This eliminates the "am I a type FOO device", because
this netdev->notifier() call would be implication only run on the correct
device types.

> Rather than a single notifier why not add a dev->notify_chain and
> do:
> 	notifier_call_chain(&netdev_chain, event, dev);
> 	notifier_call_chain(dev->notify_chain, event, dev);
> 
> But the whole programming model of responding to callbacks seems bassackwards
> in these cases, because the device can process the same events (up/down)
> on the front side (open/close) rather than getting callbacks.  At least in the
> qeth case it seems like a messed up design.  

qeth is a mess period, it tries to be overly clever because of the things it is
trying to achieve and as a result it's an abominable piece of complexity.

I don't see how a "dev->notify_chain" like scheme could work...
Oh I see, this way the driver can register multiple private device-type specific
notifiers.  Yes, this looks like a fine way to do this too.

But really, the driver too could do all of it's "notifiers" in the one dev->notifier()
method.

I'm not overly picky about using one scheme over another.