On Thu, Apr 07, 2005 at 03:24:34PM +0400, Evgeniy Polyakov wrote: > On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote: > > On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote: > > > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote: > > > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote: > > > > > The main idea was to simplify userspace control and notification > > > > > system - so people did not waste it's time learning how skb's are > > > > > allocated > > > > > and processed, how socket layer is designed and what all those > > > > > netlink_* and NLMSG* mean if they do not need it. > > > > > > > > Isn't connector built on top of netlink? If so, is there any reason for > > > > it to be a new subsystem rather than an extension the the netlink API? > > > > > > Connector is not netlink API extension in any way. > > > It uses netlink as transport layer, one can change > > > cn_netlink_send()/cn_input() > > > into something like bidirectional ioctl and use it. > > > > > > Only one cn_netlink_send() function can be "described" as API > > > extension, > > > although even it is not entirely true. > > > > I see much overlap here too. Wouldn't it be nice to see the transport > > part of the connector code to be implemented as a generic netlink > > multicast? We already have uni- and broadcast for netlink. > > Netlink broadcast is multicast actually, > if listener exists, then message will be sent to him, > if no - skb will be just freed. > > > Isn't the whole purpose of the connector to hook in notifications that > > act only if someone is listening? That is a perfect multicast case. :) > > Connector can be used to send data from userspace to kernelspace, > so it allows sending controlling messages without ioctl() compatibility > mess and so on. > > One may use cn_netlink_send() to send notification without being > registered > in connector, if it's second parameter is 0, then appropriate > connector listener will be searched for.
Sure, but seems I need to ask again: What is the exact reason not to implement the muticast message multiplexing/subscription part of the connector as a generic part of netlink? That would be nice to have and useful for other subsystems too as an option to the current broadcast. > It is different from netlink messages, > netlink is a transport layer for connector. That's still possible and the kernel usually doesn't care about unimplemented alternatives. :) Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
