[lkml]   [2005]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
    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
    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
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-04-07 13:25    [W:0.023 / U:1.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site