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
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 t
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
actuall
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
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 nes
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 earl
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-
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.
> + */
> + clear_bit
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
contro
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 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
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-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 sh
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 m
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 i
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 beca
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
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 rer
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
>
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 wh
On Fri, 2007-06-29 at 09:02 -0400, jamal wrote:
> 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 Patric
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 becaus
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 y
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
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 ther
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 thi
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
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 {
> str
jamal wrote:
> 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 d
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-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 t
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 {
> str
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
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.
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
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.
:)
Becaus
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
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 exis
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 ei
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 kern
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 r
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
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 h
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 hav
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 setso
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 yo
[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 nee
On Tue, 2007-19-06 at 13:30 +0200, Johannes Berg wrote:
> Ah, that coincides with something I was wondering about. Isn't it
> possible to have multiple multicast groups with generic netlink? If so,
> we might have to use real netlink for wireless...
There is one default mcast group per entity. M
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, acpi_even
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(mydiscover
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
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
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. :)
>
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 netlin
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 specified
I can never get these web-browser email clients to work well.
Sorry for sending fscking html earlier.
cheers,
jamal
-- Forwarded message --
From: jamal <[EMAIL PROTECTED]>
Date: May 27, 2007 9:29 AM
Subject: Re: [PATCH] [-mm] ACPI: export ACPI events via netlink
To: Zhang Rui <[E
57 matches
Mail list logo
