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
prev parent 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