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 ;-> 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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
