jamal wrote: > On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote: > >>Johannes Berg wrote: > > >>>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 ;->
That was more of a rumour :) We have 2^32-1 groups and I think 256 families, of which about 20 are used. > 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. I wouldn't reserve any, just hand them out as needed. Otherwise we'll run into problems with the af_netlink bitmaps. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
