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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux