[Linux-decnet-user] Re: DECnet routing fixes etc.

[David S. M. <da...@re...>]

   From: Steven Whitehouse <st...@gw...>
   Date: Fri, 18 Apr 2003 11:09:21 +0100 (BST)

   Ok. The new patch is attached. It would also be helpful to have the same
   infrastructure in slab too I think. Perhaps a call along the lines of:
   
   kmem_cache_module_associate(kmem_cache_t *cachep, struct module *module);
   
   (or an alternative way of initialising a slab cache) so that each allocation 
   then results in an increment of the module usage count if successful. That 
   would solve most of the problems for DECnet. It seems to be something that
   might be generally useful as it could automatically fail new allocations if
   a module unload is underway.

I can't see any legitimate situation where this cannot be solved
by other means.

Look, there are two sides to this story:

1) Gaining reference to protocol module must occur at creation point,
   ie. for sockets this is sock_create()  We have patches pending
   for this.

   Similarly for netdevice module refcounting, this occurs already.

2) Rest of details are maintained by protocol implementations already.
   There is zero reason for making module_get() f.e. each time some
   route is added to routing tables.  Similarly for creation of
   protocol specific netdev information.

   This means that knowledge of "can unload" is a local matter.

The module infrastructure does not provide a way to handle #2, but
Rusty recognizes that in order to do proper unloading for complicated
modules (such as ipv6, netfilter connection tracking, etc.) there
really does need to be such a facility.

So let's not put hacks elsewhere.

Meanwhile I'll add your updated patch to 2.5.x when I get a chance.
Thanks.