[Top] [All Lists]

Re: New module infrastructure for net_proto_family

To: Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx>
Subject: Re: New module infrastructure for net_proto_family
From: Max Krasnyansky <maxk@xxxxxxxxxxxx>
Date: Tue, 29 Apr 2003 12:21:49 -0700
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20030429014326.GA24835@xxxxxxxxxxxxxxxx>
References: <> <20030424230202.GB2931@xxxxxxxxxxxxxxxx> <> <> <> <> <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
At 06:43 PM 4/28/2003, Arnaldo Carvalho de Melo wrote:
>Em Mon, Apr 28, 2003 at 02:10:11PM -0700, Max Krasnyansky escreveu:
>> Hi Arnaldo,
>> Hmm, no comments on my last email 
>> ( 
>> Are you trying to ignore me too ? ;-)
>Nope, I was working on the higher layer first, to then come to the net families
>that are already modular and have per-protocol modules, and I'm starting to 
>into the only, AFAIK, network family that has this in place: bluetooth :-)
>Having said that I haven't fully studied this I see two scenarios 
>1. the net family that wants per protocol "sub" modules "duplicates" the
>infrastructure having PROTO_sk_alloc and PROTO_destruct (the sk_free
>sk->destruct hook call), PROTO_sk_alloc uses its net_families equivalent
>(bt_proto in bluetooth) to find the owner (the "sub" module, i.e. per protocol
>module) and PROTO_net_family_gets it, then calls sk_alloc proper, and when the
>last reference to the sock is released the sk->destruct is called
>(PROTO_destruct) does the PROTO_net_family_put. Ditto for the socket case,
>where PROTO_create, before calling the ->create of the "sub" module does the
>PROTO_net_family_get, and at release time its PROTO_release does the same thing
>that sock_release does. Something like this may well need extra info to be kept
>at the private area of the proto family in struct sock protinfo or private slab
That can probably be done. But what happened to "protocol writers don't have to
worry about this issues" ideas though ;-) ?
The other thing that I don't like is that to create one socket we'd have to 
call whole bunch of functions to take care of the module refcounting.
So I want to bring these questions again: 
- Why do we have to bump module refcount for 'struct sock' with _default_ 
callbacks ?
My answer is that we don't have to. I'd even say that we shouldn't. Module is 
referenced from struct sock in that case.

- Why are we not allowing net_family unregistration until all family sockets 
are gone ?
 From what I see it's only because current code does 
I'm saying that we don't care whether net_family is registered or not if we 
know who owns
the socket (i.e. sock->owner).

So my point is yes we can make families to implement their own infrastructure 
for module
refcounting. But the solution is going to be more complicated than just having 
and sk->owner fields and allowing for ownership transfers.

>That is, we have a higher layer for net families, with locking for the whole
>family done like it is on the tree now and a lower layer at the specific
>net family, both having the same behaviour at its layers.
>This option seems to be easy to implement with the current bluetooth
>infrastructure (i.e. it has a net_families equivalent, it does the switching at
>bt_create time, etc).
Well, we already use sk->destruct call back in Bluetooth protocols (each proto 
has its 
own call back that does different things). I think we should not use existing 
sk call 
backs for module refcounting.


<Prev in Thread] Current Thread [Next in Thread>