On Mon, 2007-07-02 at 16:48 +0200, Johannes Berg wrote:
If I find time I might
actually fix the unregistration bug too, but I have a feeling digging in
the socket code might take more time than I have right now.
Hmm. I started digging into the af_netlink.c code and realised that the
whole
Johannes Berg wrote:
On Mon, 2007-07-02 at 16:48 +0200, Johannes Berg wrote:
If I find time I might
actually fix the unregistration bug too, but I have a feeling digging in
the socket code might take more time than I have right now.
Hmm. I started digging into the af_netlink.c code and
On Sat, 2007-06-30 at 11:32 -0400, jamal wrote:
+static void genl_unregister_mc_group(struct genl_multicast_group *grp)
+{
+ /*
+* TODO: fix multicast group re-use by clearing the bit
+* for this group in all genetlink sockets.
+*/
+ clear_bit(grp-id,
Johannes Berg wrote:
On Sat, 2007-06-30 at 11:32 -0400, jamal wrote:
+NLA_PUT_U32(skb, CTRL_ATTR_MCAST_GRP_ID, grp-id);
+NLA_PUT_STRING(skb, CTRL_ATTR_MCAST_GRP_NAME,
+ grp-name);
+
Consider my earlier suggestion to
On Mon, 2007-07-02 at 14:56 +0200, Patrick McHardy wrote:
For information that belongs together logically a struct is fine.
Ok.
The main reason to use nested attributes is when you only have a
single attribute to store your data in (for example TCA_OPTIONS
for qdiscs). In that case a nested
Johannes Berg wrote:
On Mon, 2007-07-02 at 14:56 +0200, Patrick McHardy wrote:
The main reason to use nested attributes is when you only have a
single attribute to store your data in (for example TCA_OPTIONS
for qdiscs). In that case a nested attribute should be used to
allow to extend it in
On Mon, 2007-07-02 at 16:38 +0200, Patrick McHardy wrote:
Do I understand you correctly in that you prefer the way I did it now?
Yes.
Alright, then I'll rework the event generation to not include the whole
family info and repost with that tomorrow or so. If I find time I might
actually
On Fri, 2007-29-06 at 16:56 +0200, Johannes Berg wrote:
+static void genl_unregister_mc_group(struct genl_multicast_group *grp)
+{
+ /*
+ * TODO: fix multicast group re-use by clearing the bit
+ * for this group in all genetlink sockets.
+ */
+
On Thu, 2007-28-06 at 11:45 +0200, Johannes Berg wrote:
No, the controller is the only other generic netlink multicast user
according to what I've found. :)
Scanning the code - true ;- Iam a little suprised that the task
accounting folks didnt use it to periodically dump stats.
actually
Johannes Berg wrote:
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
c) Use a global hash table to store all the genl_multicast_groups;
I think this (handwaving) should be searchable by i) name ii)ID and iii)
family.
Yeah, makes sense, I never liked the bitmap stuff I did there.
Do
On Fri, 2007-06-29 at 07:17 -0400, jamal wrote:
No, the controller is the only other generic netlink multicast user
according to what I've found. :)
Scanning the code - true ;- Iam a little suprised that the task
accounting folks didnt use it to periodically dump stats.
:)
Because of
On Fri, 2007-29-06 at 13:28 +0200, Johannes Berg wrote:
On Fri, 2007-06-29 at 07:17 -0400, jamal wrote:
Because of this I'd really prefer if we could hold off on adding groups,
but I can handle both cases fine by just reserving a family and group ID
for the current users.
sure - if you
On Fri, 2007-06-29 at 07:48 -0400, jamal wrote:
sure - if you rush you can make it into Daves 2.6.23; then both can
conform at the same time.
Yeah, I'll have to see whether I can make that. If not, no big deal
either.
Ok :) Though I'm not sure I understood the suggestion of sending just
On Fri, 2007-29-06 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name?
As i see it: the name would be unique per family
Its like DNS IP to name mapping essentially (in the simple case of IP
being globaly reachable). You do a discovery of the ID by knowing
Johannes Berg wrote:
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name? Or would it suffice
to have them associated with the genl family and be able to find out
the starting group number? In that case something like
struct
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name? Or would it suffice
to have them associated with the genl family and be able to find out
the starting group number? In that case something like
struct genl_mc_groups {
struct
Johannes Berg wrote:
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name? Or would it suffice
to have them associated with the genl family and be able to find out
the starting group number? In that case something like
struct
On Fri, 2007-06-29 at 14:48 +0200, Patrick McHardy 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
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name? Or would it suffice
to have them associated with the genl family and be able to find out
the starting group number? In that case something like
struct genl_mc_groups {
struct
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
a) i.e other than the reserved group for controller (which you seem to
be taking care of), every other genetlink user has to explicitly
register when they need a mcast group.
Hm. I'm starting to dislike the dynamic registration the more I think
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
On Fri, 2007-29-06 at 15:15 +0200, Johannes Berg wrote:
(1) register group X with non-root
(2) non-root app A binds group X
(3) kernel unregisters group X
Kernel sends event (controller) Group X is gone or family Y which
used to own group X is gone
(4) something else in kernel
On Fri, 2007-29-06 at 14:57 +0200, Johannes Berg wrote:
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
Hm. I'm starting to dislike the dynamic registration the more I think
about it. Now when a group is unregistered I'd have to unbind everybody
who's currently using it...
I understood you
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
Johannes Berg wrote:
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
a) i.e other than the reserved group for controller (which you seem to
be taking care of), every other genetlink user has to explicitly
register when they need a mcast group.
Hm. I'm starting to dislike the dynamic
On Fri, 2007-06-29 at 15:11 +0200, Patrick McHardy wrote:
Hm. I'm starting to dislike the dynamic registration the more I think
about it. Now when a group is unregistered I'd have to unbind everybody
who's currently using it... At least when I want to enforce
root/non-root binds which is
Johannes Berg wrote:
On Fri, 2007-06-29 at 15:11 +0200, Patrick McHardy wrote:
Hm. I'm starting to dislike the dynamic registration the more I think
about it. Now when a group is unregistered I'd have to unbind everybody
who's currently using it... At least when I want to enforce
jamal wrote:
On Fri, 2007-29-06 at 15:12 +0200, Patrick McHardy wrote:
jamal wrote:
On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
Our philosophy in genetlink is to have dynamic resources allocated and
released - remember the real reason we even have this is because we were
On Fri, 2007-06-29 at 15:23 +0200, Patrick McHardy wrote:
I'm not sure that the only sensible thing to do is right, we
do allow dynamic registration of netlink families and do the
module reference thing anyway (admittedly, I never liked that
and the autoloading part very much). I guess it
Johannes Berg wrote:
On Fri, 2007-06-29 at 15:23 +0200, Patrick McHardy wrote:
If you do want the dynamic unregistation *and* the non-root mc
listening then I guess you don't have a choice but to unbind
sockets at unregistration. That shouln't be a real problem,
without having though much about
On Fri, 2007-06-29 at 15:44 +0200, Patrick McHardy wrote:
How about for now I only allow dynamic registration (no unregistration)
and just send out when new groups are registered, and also give
userspace a list of registered mc groups when they ask for a family
description? That should
Johannes Berg wrote:
On Fri, 2007-06-29 at 15:44 +0200, Patrick McHardy wrote:
How about for now I only allow dynamic registration (no unregistration)
and just send out when new groups are registered, and also give
userspace a list of registered mc groups when they ask for a family
On Fri, 2007-29-06 at 15:12 +0200, Patrick McHardy wrote:
jamal wrote:
On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
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
On Fri, 2007-06-29 at 15:53 +0200, Patrick McHardy wrote:
If you're worried about patch size, you could sell that part as a
bugfix :)
Heh. Actually, right now I'm more worried about how much work I have to
do short-term.
This patch keeps the bitmap but does dynamic group allocation. Just to
On Fri, 2007-06-29 at 16:05 +0200, Johannes Berg wrote:
+ mc_groups =
+ kzalloc(mc_groups_bits/BITS_PER_LONG + 1,
+ GFP_KERNEL);
+ if (!mc_groups)
+ return
On Fri, 2007-06-29 at 16:19 +0200, Johannes Berg wrote:
Uh huh, this reallocation is buggy. Fixed version below.
More breakage, sorry about the patch-spam.
Btw, I notice that the bug we talked about isn't present in practice
since we have no multicast users except for the always-present
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote:
I wonder if we should hold off on this API until we've worked out the
multicast issue.
Even if the ACPI thing goes in first, you will have to change a few
others that are existing
On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote:
I wonder if we should hold off on this API until we've worked out the
multicast issue.
Even if the ACPI thing goes in first, you will have to change a few
others that are existing in-kernel that need to be changed sooner or
later. So
On Mon, 2007-06-25 at 13:08 -0400, jamal wrote:
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.
I think it could be done. You will need to have
On Tue, 2007-06-19 at 11:32 +0800, Zhang Rui wrote:
Ok, by inspection (sorry, still dont have much time) - your kernel code
is sending to group 1; i.e
genlmsg_multicast(skb, 0, 1, GFP_ATOMIC);
you need to change that to send to your assigned id, i.e:
genlmsg_multicast(skb, 0,
On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote:
I wonder if we should hold off on this API until we've worked out the
multicast issue.
I think we can fix all the code in one shot later. I just glanced at
your patch but i have to run out, i will stare at it later - seems to be
in the
On Tue, 2007-06-26 at 09:33 -0400, jamal wrote:
On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote:
I wonder if we should hold off on this API until we've worked out the
multicast issue.
I think we can fix all the code in one shot later.
Yes, we could fix the code in the kernel, but
On Fri, 2007-22-06 at 12:09 +0200, Johannes Berg wrote:
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.
I think it could be done. You will need to have
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
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.
Btw, what happens if the group id gets larger than 31?
You can use setsockopt to set the multicast groups. What you
[took off acpi list]
On Tue, 2007-06-19 at 12:20 -0400, jamal wrote:
There is one default mcast group per entity. Most users only need that
one.
Ok. That's definitely a bug in nl80211 as we have it in development
right now. Btw, what happens if the group id gets larger than 31?
If you need
On Mon, 2007-06-18 at 11:01 -0400, jamal wrote:
Ok, by inspection (sorry, still dont have much time) - your kernel code
is sending to group 1; i.e
genlmsg_multicast(skb, 0, 1, GFP_ATOMIC);
you need to change that to send to your assigned id, i.e:
genlmsg_multicast(skb, 0,
On Fri, 2007-15-06 at 09:01 +0800, Zhang Rui wrote:
I dont have much time to look at your code given travel, but did you
try to use your group id instead of the controller's?
i.e:
rtnl_open_byproto(rth, nl_mgrp(mydiscoveredacpiid), NETLINK_GENERIC)
Yes. It doesn't work if I use my
On Mon, 2007-06-18 at 11:01 -0400, jamal wrote:
On Fri, 2007-15-06 at 09:01 +0800, Zhang Rui wrote:
I dont have much time to look at your code given travel, but did you
try to use your group id instead of the controller's?
i.e:
rtnl_open_byproto(rth, nl_mgrp(mydiscoveredacpiid),
On Fri, 2007-15-06 at 09:01 +0800, Zhang Rui wrote:
rtnl_open_byproto(rth, nl_mgrp(mydiscoveredacpiid), NETLINK_GENERIC)
Yes. It doesn't work if I use my group id here.
In fact, I'm using rtnl_open_byproto(rth, 1, NETLINK_GENERIC) now.
That's why I said that this demo receives all the
Hi, Jamal,
Now the genl utility can find the acpi event genetlink family.
And a simple user space demo is finished for handling acpi event.
I really appreciate your help. :)
I think the patch which exposes ACPI events via netlink is ok.
But I still have some problems on
how to listen to
On Thu, 2007-14-06 at 16:59 +0800, Zhang Rui wrote:
Hi, Jamal,
Now the genl utility can find the acpi event genetlink family.
And a simple user space demo is finished for handling acpi event.
I really appreciate your help. :)
np.
I think the patch which exposes ACPI events via netlink is
On Thu, 2007-06-14 at 07:28 -0400, jamal wrote:
On Thu, 2007-14-06 at 16:59 +0800, Zhang Rui wrote:
Hi, Jamal,
Now the genl utility can find the acpi event genetlink family.
And a simple user space demo is finished for handling acpi event.
I really appreciate your help. :)
np.
I
53 matches
Mail list logo
