[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4684F68B.5030805@trash.net>
Date: Fri, 29 Jun 2007 14:09:47 +0200
From: Patrick McHardy <kaber@...sh.net>
To: hadi@...erus.ca
CC: Johannes Berg <johannes@...solutions.net>,
Zhang Rui <rui.zhang@...el.com>, netdev@...r.kernel.org,
"linux-acpi@...r" <linux-acpi@...r.kernel.org>, lenb@...nel.org,
Thomas Graf <tgraf@...g.ch>
Subject: Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
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 discovery of the ID by knowing the
> name.
Mhh .. I agree that it would be necessary to have a group identifier
for dynamically allocated groups like one group per device or something.
I'm wondering if anyone really needs this though. Having messages
grouped logically by type makes more sense to me.
>>Or would it suffice
>>to have them associated with the genl family and be able to find out
>>the starting group number?
>
>
> The id space is global.
>
>
>>In that case something like
>>
>>struct genl_mc_groups {
>> struct genl_family *family or char *family_name or similar;
>> unsigned int group_off;
>> unsigned int group_num;
>> unsigned long groups[];
>>};
>>
>>seems to make more sense since you only need a single struct
>>per family.
>
>
> I think something that ties to the family would be needed.
My example includes a pointer to the family or the name, but anything
else that works is fine also.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists