Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

Johannes Berg
2007-06-29T11:28:47Z

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

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 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.

> Sorry i meant there are 2^16 families (-1 considering controller)
> There are 2^32 groups (-1 considering controller) for the same number of
> families. i.e i see those items as being global within genetlink.

Yeah, so we shouldn't really be worried about running out of either.

> It is just a boundary condition policy. When there are no more groups
> left (Note: it will take a lot of effort to hit that), then what do you
> do?
> Your current approach seems to say "return an error".

[suggestion snipped]

I think I'd prefer if we just returned an error. See, we aren't going to
run out of groups in the foreseeable future, and if we ever have users
that generate *a lot* of groups we can still add the sharing code etc.
For now it seems just bloat and a code path we won't ever touch so prone
to errors in it.

> > Why give them
> > numbers from a different namespace because they're used inside nested
> > attributes?
>
> Sorry - i should have read up to here ;-> Yes, it is because of the
> nesting. Again consider the suggestion of sending just one TLV.

Ok :) Though I'm not sure I understood the suggestion of sending just
one TLV, what should I send? Or are you referring to dynamic group
registration where the whole nesting is going away anyway since you get
one message per new group...

> Well, you can hide that from the user in the form of a library etc. They
> dont have to know; what they know is group named "link-events" is where
> they can join to listen to link events (and your abstraction generic
> code does all the dirty work).

Right. We'll see how it turns out in practice when we start using it :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]