| To: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Netlink Connector / CBUS |
| From: | Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxx> |
| Date: | Tue, 05 Apr 2005 10:11:23 +0200 |
| Cc: | lkml <linux-kernel@xxxxxxxxxxxxxxx>, Netlink List <netdev@xxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, James Morris <jmorris@xxxxxxxxxx>, rml@xxxxxxxxxx, Greg KH <greg@xxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, Evgeniy Polyakov <johnpol@xxxxxxxxxxx> |
| In-reply-to: | <1112686480.28858.17.camel@uganda> |
| References: | <Xine.LNX.4.44.0504050108260.9383-100000@thoron.boston.redhat.com> <1112686480.28858.17.camel@uganda> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Tue, 2005-04-05 at 11:34 +0400, Evgeniy Polyakov wrote: > On Tue, 2005-04-05 at 01:10 -0400, Herbert Xu wrote: > > >In fact to this day I still don't understand what problems this thing is > >meant to solve. > > Hmm, what else can I add to my words? > May be checking the size of the code needed to broadcast kobject changes > in kobject_uevent.c for example... > Netlink socket allocation + skb handling against call to cn_netlink_send(). And It's the same for the fork connector. It allows to send a message to a user space application when a fork occurs by adding only one line (two with the #include) in the kernel/fork.c file. Thus, the netlink connector is a very simple and fast mechanism when you need to send a small amount of information from kernel space to user space. Regards, Guillaume |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: take 2-2 WAS(Re: PATCH: IPSEC xfrm events, Masahide NAKAMURA |
|---|---|
| Next by Date: | Some sleeping function called from invalid context, Marcel Holtmann |
| Previous by Thread: | Re: Netlink Connector / CBUS, Evgeniy Polyakov |
| Next by Thread: | Re: Netlink Connector / CBUS, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |