Netdev List
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <hadi@cyberus.ca>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: netdev@vger.kernel.org, davem@davemloft.net, tgraf@suug.ch,
	jlan@engr.sgi.com, nagar@watson.ibm.com, per.liden@ericsson.com
Subject: Re: [DOC]: generic netlink
Date: Fri, 14 Jul 2006 07:43:33 -0400	[thread overview]
Message-ID: <1152877414.5125.40.camel@jzny2> (raw)
In-Reply-To: <20060713105028.b262b95e.rdunlap@xenotime.net>

On Thu, 2006-13-07 at 10:50 -0700, Randy.Dunlap wrote:
> On Mon, 19 Jun 2006 09:41:22 -0400 jamal wrote:
> 
> > 
> > Folks,
> > 
> > Attached is a document that should help people wishing to use generic
> > netlink interface. It is a WIP so a lot more to go if i see interest.
> 
> Hi,
> I have a few random questions about gen-netlink.
> 
> 1.  Provider IDs (numbers) and names must be unique.  Does
> this affect virtualization in any way or is it just transparent?
> 

You are referring to the openvz type of virtualization i suspect, no?
i.e not XEN or UML etc.
Good question. I think whatever those folks do for standard sockets will
work in this case as well; it is related to the way they handle process
management in the different virtual compartments. So if standard netlink
is transparent, I believe gen-netlink will be as well. A quick test is
to run "ip mon" on one VE and see if adding a route on another generates
an event on the former VE.

> 2.  Is (generic) netlink meant (expected, OK) to be used for
> non-networking ioctl/sysfs replacements?

It is OK to be used but i am not sure if we are saying it is _the_
replacement for ioctls for example. It certainly has many advantages
over ioctl/sysfs - eg (an incomplete list):
- ability to generate asynchronous events from the kernel. 
- ability to do bulk transfers from/to the kernel to/from user-space
(look at the way what Shailabh is working on may end up transmitting
upto a few MB of data from the kernel at a time)
- ability to do simple attribute set/get/event or a complex
(multi-nested) vector of such attributes
- ability to act as an IPC between user-user or user-kernel
- ability to do  one to many communication; so a single user space
message could be sent to many kernel _and user_ destinations and the
reverse a single kernel message could be sent to many kernel or user
listeners.
- the fact that it is a "a network wire" format allows for it to be used
for inter-machine communication (in a distributed system type setup for
example). 

etc

Try doing the above with ioctl or sysfs ;->

cheers,
jamal


      reply	other threads:[~2006-07-14 11:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-19 13:41 [DOC]: generic netlink jamal
2006-06-19 15:13 ` James Morris
2006-06-19 15:28   ` jamal
2006-06-19 15:54     ` James Morris
2006-06-20 12:59       ` jamal
2006-06-19 15:58     ` Shailabh Nagar
2006-06-20 13:19       ` jamal
2006-06-19 22:37 ` Shailabh Nagar
2006-06-20 14:50   ` jamal
2006-07-11 23:57     ` Randy.Dunlap
2006-07-12 11:30       ` Jamal Hadi Salim
2006-07-12 15:16         ` Shailabh Nagar
2006-06-20  8:02 ` Thomas Graf
2006-06-20 15:01   ` jamal
2006-06-20 21:34     ` Thomas Graf
2006-06-22 19:07       ` jamal
2006-07-13 17:50 ` Randy.Dunlap
2006-07-14 11:43   ` Jamal Hadi Salim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1152877414.5125.40.camel@jzny2 \
    --to=hadi@cyberus.ca \
    --cc=davem@davemloft.net \
    --cc=jlan@engr.sgi.com \
    --cc=nagar@watson.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=per.liden@ericsson.com \
    --cc=rdunlap@xenotime.net \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox