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. It is different from netlink messages, netlink is a transport layer for connector. > At the time we added kobject_uevent I was missing something like this. > The broadcast groups did not really fit, and we decided not to use them, > and unicast wasn't a option here. There is a check for listener in netlink_broadcast() - sk_for_each_bound (). > Thanks, > Kay -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- From: Kay Sievers <[email protected]>
- Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- References:
- Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- From: Evgeniy Polyakov <[email protected]>
- Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- From: Ian Campbell <[email protected]>
- Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- From: Evgeniy Polyakov <[email protected]>
- Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- From: Kay Sievers <[email protected]>
- Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- Prev by Date: Re: alsa es1371's joystick functionality broken in 2.6.11-mm4
- Next by Date: Re: [PATCH] Use proper seq_file api for /proc/scsi/scsi
- Previous by thread: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- Next by thread: Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
- Index(es):