Messages in this thread | | | Date | Sun, 04 Apr 2004 09:11:26 +0200 | From | Manfred Spraul <> | Subject | Re: [RFC, PATCH] netlink based mq_notify(SIGEV_THREAD) |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |