netdev
[Top] [All Lists]

Re: [RFC, PATCH] netlink based mq_notify(SIGEV_THREAD)

To: hadi@xxxxxxxxxx
Subject: Re: [RFC, PATCH] netlink based mq_notify(SIGEV_THREAD)
From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
Date: Sun, 04 Apr 2004 09:11:26 +0200
Cc: netdev@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Michal Wronski <wrona@xxxxxxxxxxxxxxxx>, Krzysztof Benedyczak <golbi@xxxxxxxxxxxxxxxx>
In-reply-to: <1081029667.2037.55.camel@jzny.localdomain>
References: <406F13A1.4030201@colorfullife.com> <1081023487.2037.19.camel@jzny.localdomain> <406F21FB.4010502@colorfullife.com> <1081029667.2037.55.camel@jzny.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4.1) Gecko/20031114
jamal wrote:

Your split of netlink_unicast seems fine ; I guess the bigger question is whether this interface could be a
speacilized netlink protocol instead? It doesnt seem too nasty as is
right now, just tending towards cleanliness.
It seems that user space must first open a netlink socket for this to
work but somehow the result skb is passed back to userspace using the
mq_notify and not via the socket interface opened?


No, the result is returned via the socket fd. It's just created due to the mq_notify call.

Why should user space
even bother doing this? The kernel could on its behalf, no? Are you sure
there will always be one and only one message outstanding always?


There can be multiple messages outstanding. Each sucessful mq_notify call generates exactly one message, but a process could create multiple message queues and then there can be multiple messages in the notification socket.

--
   Manfred


<Prev in Thread] Current Thread [Next in Thread>