[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1182506947.21939.89.camel@johannes.berg>
Date: Fri, 22 Jun 2007 12:09:06 +0200
From: Johannes Berg <johannes@...solutions.net>
To: hadi@...erus.ca
Cc: Zhang Rui <rui.zhang@...el.com>, netdev@...r.kernel.org,
lenb@...nel.org
Subject: Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Thu, 2007-06-21 at 11:47 -0400, jamal wrote:
> On Wed, 2007-20-06 at 13:25 +0200, Johannes Berg wrote:
>
> > Ok. That's definitely a bug in nl80211 as we have it in development
> > right now.
>
> Sorry, have never looked at that code.
No worries, I was just stating that.
> You can use setsockopt to set the multicast groups. What you cant do
> with that is subscribe to many groups in one shot.
> The call in iproute2 hasnt reflected this reality yet.
Ah, ok, I see now. I was under the impression that groups was always
just a u32.
> > I'd really like to be able to reserve multicast groups with special
> > semantics too, especially I might want to permit/deny non-CAP_NET_ADMIN
> > users from binding specific multicast groups. That isn't actually
> > possible with netlink nor genetlink right now afaict.
>
> This would be hard - but doable via SELinux interface. I think you
> should be able to extend your tool to make calls to that interface.
Why do you think that would be hard? It'd basically just mean replacing
the netlink_capable(sock, NL_NONROOT_RECV) calls with a call that
actually tests depending on the group(s) it wants.
> > If we register multiple IDs then we'll end up filling up the generic
> > netlink family space really soon.
>
> Theres a huge number of these groups; and not just that, but considering
> that some genetlink users may not be interested in such multicast
> groups, it is quiet usable to have many groups as long as we avoid
> conflict.
Yeah, never mind, I thought that the number of groups was limited to 32.
> The multicast issue wasnt well-attacked. We have a group magically
> assigned to a user based on their allocated id. It should be feasible
> to add an API to the kernel for registering for many groups and allow
> user space to discover these groups before registering. Maybe thats
> the path to proceed to.
Yeah, sounds reasonable, you could ask the controller for which groups
are attached to a family and then get the IDs for those groups by name.
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)
Powered by blists - more mailing lists