On Wed, 2007-07-04 at 16:04 +0400, Evgeniy Polyakov wrote: > On Tue, Jul 03, 2007 at 09:51:25PM +0200, Johannes Berg ([EMAIL PROTECTED]) > wrote: > > Does anybody have any better ideas?
> Why don't you want to reserve a set of bits in group number, which means > 'allow to work with unpriveledged users', that bits should not cross existing > users (hardcoded in various files in kernel), all new code can use that > groups. Uh wait, we're confusing two issues here. This idea actually makes good sense, although it'd have to be two bits (allow unpriv users to recv, allow unpriv users to send), limiting the groups to 2^30-1. Fine with me. However, the actual issue I wanted to address with this mail is that we cannot have userspace send to groups > 32. However, your idea above can equally well apply here; we could say some bit in the nl_groups field is reserved and that if that bit is set the other bits form the group number to send to instead of a bitfield where the highest group is sent to. That should work fine, both limits the number of available groups to 2^30 respectively 2^31 but that's not an issue. The thing with actually trying to fix this issue now is that when we have generic netlink and multicast group registrations, we'll have userspace programs sending to a multicast group using nl_groups = (1<<group.id) and then group.id grows > 32 if a whole bunch of other groups were registered before, and it all messes up. Hence we actually have to address this issue well before userspace starts using the generic netlink multicast API. johannes
signature.asc
Description: This is a digitally signed message part
