On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:

Johannes Berg wrote:

quoted

Hmm, another thought: since we have 32 bits for group numbers and 16
bits for families we could just reserve 16 bits for groups within each
family. Or do we get trouble with that because in some place there's a
group bitmap or such?

Yes, af_netlink has a bitmap per socket that is subscribed to any group.

I think this is the challenge. The groups belong to a global namespace.
i.e when you do a socket bind to group - it is unique regardless of the
family.
Our philosophy in genetlink is to have dynamic resources allocated and
released - remember the real reason we even have this is because we were
running out of numbers ;->
So while the static allocation of 16 bits per group will work (famous
last words "noone will ever need more than 640K of RAM";->) it will be
cleaner imo to allow dynamic allocation/release.
Maybe a mix (of a few static and mostly dynamic) as Patrick says - but
that would mean more coding for you ;-> Actually i like the idea of at
least your ID being your static mcast group and the rest are in the
dynamic pool (Hey, thanks Patrick;->). This means the first 2^16 are
static/reserved and if you want more groups, you register for them.

cheers,
jamal