Havent seen the beginnings of this thread. But whatever you are trying
to do seems to suggest some complexity that you are trying to
workaround. What was wrong with just going ahead and just always
invoking your netlink_send()? If there are nobody in user space (or
kernel) listening, it wont go anywhere.
On Mon, 2005-02-28 at 02:39, Andrew Morton wrote:
> Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxx> wrote:
> > Ok the protocol is maybe too "basic" but with this mechanism the user
> > space application that uses the fork connector can start and stop the
> > send of messages. This implementation needs somme improvements because
> > currently, if two application are using the fork connector one can
> > enable it and the other don't know if it is enable or not, but the idea
> > is here I think.
> Yes. But this problem can be solved in userspace, with a little library
> function and a bit of locking.
> IOW: use the library to enable/disable the fork connector rather than
> directly doing syscalls.
> It has the problem that if a client of that library crashes, the counter
> gets out of whack, but really, it's not all _that_ important, and to handle
> this properly in-kernel each client would need an open fd against some
> object so we can do the close-on-exit thing properly. You'd need to create
> a separate netlink socket for the purpose.
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> Lse-tech mailing list