Re: [DOC]: generic netlink
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
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? 2. Is (generic) netlink meant (expected, OK) to be used for non-networking ioctl/sysfs replacements? Thanks, --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
On Tue, 2006-11-07 at 16:57 -0700, Randy.Dunlap wrote: so make it a patch to Documentation/networking/... I was going to when it got in better shape. Good suggestion, I will do this soon and put it there as a patch. I have some doc corrections, Jamal. Do I send them against the 2006-june-19 doc posting? and as email comments or as a patch? There has been some small changes; last time i punted it to Shailabh for additional changes. You can extend the attached version (from june 20) or send me a patch - whichever is convinient. cheers, jamal 1.0 Problem Statement --- Netlink is a robust wire-format IPC typically used for kernel-user communication although could also be used to be a communication carrier between user-user and kernel-kernel. A typical netlink connection setup is of the form: netlink_socket = socket(PF_NETLINK, socket_type, netlink_family); where netlink_family selects the netlink bus to communicate on. Example of a family would be NETLINK_ROUTE which is 0x0 or NETLINK_XFRM which is 0x6. [Refer to RFC 3549 for a high level view and look at include/linux/netlink.h for some of the allocated families]. Over the years, due to its robust design, netlink has become very popular. This has resulted in the danger of running out of family numbers to issue. In netconf 2005 in Montreal it was decided to find ways to work around the allocation challenge and as a result NETLINK_GENERIC bus was born. This document gives a mid-level view if NETLINK_GENERIC and how to use it. The reader does not necessarily have to know what netlink is, but needs to know at least the encapsulation used - which is described in the next section. There are some implicit assumptions about what netlink is or what structures like TLVs are etc. I apologize i dont have much time to give a tutorial - invite me to some odd conference and i will be forced to do better than this doc. Better send patches to this doc. 2.0 Overview - In order to illustrate the way different components talk to each other, the diagram below is used to provide an abstraction on how the operations happen. 1) The generic netlink connection which for illustration is refered to as a bus. The generic netlink bus is shown as split between user and kernel domains: This means programs can connect to the bus from either kernel or user space. 2) Users : who use the connection to get information or set variables. These are typically programs in user space but don't have to be. 3) Providers: who supply the information sent through the connection or to execute kernel functions in response to user commands. This is always some kernel subsystem, typically but not necessarily a module. 4) Commands: which typically define what is sent by the user and acted upon by the provider. Commands are registered with the generic netlink bus by providers. In the diagram, controller, foobar and googah are providers, user1 through user-n users in userspace and kuser-1 a user in kernel space. For brevity, kernel space users are not discussed further. All boxes have kernel-wide unique identifiers that can be used to address them. Any users can communicate with one or more providers. The interface to a provider is defined primarily by the commands it exports as well as the optional provider specific headers that it mandates in messages exchanged with users, explained further below. +--+ +--+ | user1 | .. | user-n | +--+---+ +---+--+ | | / | | |User +-++-+ Space/domain user || + Generic Netlink Bus +--- kernel || Kernel +--+--+--+ Space/domain || | \ || |\ +-+ || | \_ | kuser-1 | || |+-+ +--+---++---+-+ +--+-+ |controller|| foobar | | googah | +--++-+ ++ The controller is a special built-in provider. It is the repository of info on other providers attached to the bus. It has a reserved address identifier of 0x10. By querying the controller, one could find out that both foobar and googah are registered and what their IDs are etc. Essentially its a namespace translator not unlike DNS is for IP addresses. More later on this. To get to the point of the most common usage of netlink (user space control of a kernel component), the diagram below breaks things down
Re: [DOC]: generic netlink
Jamal Hadi Salim wrote: On Tue, 2006-11-07 at 16:57 -0700, Randy.Dunlap wrote: so make it a patch to Documentation/networking/... I was going to when it got in better shape. Good suggestion, I will do this soon and put it there as a patch. I have some doc corrections, Jamal. Do I send them against the 2006-june-19 doc posting? and as email comments or as a patch? There has been some small changes; last time i punted it to Shailabh for additional changes. Sorry, haven't had time to finish up the discussions and changes on account of the flurry of stuff going on for delay accounting patches. You can extend the attached version (from june 20) or send me a patch - whichever is convinient. cheers, jamal 1.0 Problem Statement --- Netlink is a robust wire-format IPC typically used for kernel-user communication although could also be used to be a communication carrier between user-user and kernel-kernel. A typical netlink connection setup is of the form: netlink_socket = socket(PF_NETLINK, socket_type, netlink_family); where netlink_family selects the netlink bus to communicate on. Example of a family would be NETLINK_ROUTE which is 0x0 or NETLINK_XFRM which is 0x6. [Refer to RFC 3549 for a high level view and look at include/linux/netlink.h for some of the allocated families]. Over the years, due to its robust design, netlink has become very popular. This has resulted in the danger of running out of family numbers to issue. In netconf 2005 in Montreal it was decided to find ways to work around the allocation challenge and as a result NETLINK_GENERIC bus was born. This document gives a mid-level view if NETLINK_GENERIC and how to use it. The reader does not necessarily have to know what netlink is, but needs to know at least the encapsulation used - which is described in the next section. There are some implicit assumptions about what netlink is or what structures like TLVs are etc. I apologize i dont have much time to give a tutorial - invite me to some odd conference and i will be forced to do better than this doc. Better send patches to this doc. 2.0 Overview - In order to illustrate the way different components talk to each other, the diagram below is used to provide an abstraction on how the operations happen. 1) The generic netlink connection which for illustration is refered to as a bus. The generic netlink bus is shown as split between user and kernel domains: This means programs can connect to the bus from either kernel or user space. 2) Users : who use the connection to get information or set variables. These are typically programs in user space but don't have to be. 3) Providers: who supply the information sent through the connection or to execute kernel functions in response to user commands. This is always some kernel subsystem, typically but not necessarily a module. 4) Commands: which typically define what is sent by the user and acted upon by the provider. Commands are registered with the generic netlink bus by providers. In the diagram, controller, foobar and googah are providers, user1 through user-n users in userspace and kuser-1 a user in kernel space. For brevity, kernel space users are not discussed further. All boxes have kernel-wide unique identifiers that can be used to address them. Any users can communicate with one or more providers. The interface to a provider is defined primarily by the commands it exports as well as the optional provider specific headers that it mandates in messages exchanged with users, explained further below. +--+ +--+ | user1 | .. | user-n | +--+---+ +---+--+ | | / | | |User +-++-+ Space/domain user || + Generic Netlink Bus +--- kernel || Kernel +--+--+--+ Space/domain || | \ || |\ +-+ || | \_ | kuser-1 | || |+-+ +--+---++---+-+ +--+-+ |controller|| foobar | | googah | +--++-+ ++ The controller is a special built-in provider. It is the repository of info on other providers attached to the bus. It has a reserved address identifier of 0x10. By querying the controller, one could find out that both foobar and googah are registered and what
Re: [DOC]: generic netlink
On Tue, 20 Jun 2006 10:50:13 -0400 jamal wrote: PS:- I dont have a good place to put this doc and point to, hence the 17K attachment http://www.kernel.org/pub/linux/kernel/people/hadi/ ? (unless your permissions have been revoked for lack of use ! :-) I am only allowed to put kernel patches there by the powers that be. So this wont fit the criteria. It is hard to believe in these times my ISP charges me $1/M/month every time i exceed my allocated 5M quota. I have been with this ISP for 10 years, hence migration gets harder - and given that many years on the same account, even my .bashrc approaches 5M ;- so make it a patch to Documentation/networking/... I have some doc corrections, Jamal. Do I send them against the 2006-june-19 doc posting? and as email comments or as a patch? thanks, --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
On Tue, 2006-20-06 at 23:34 +0200, Thomas Graf wrote: Ask Mr. Mashimaro has become my replacement for 8ball. Renaming it would lead to a serious loss of coolness ;-) ;- Blame Dave for that ;- I think if you put it in some website, I will just add a url to point to it. Shailabh has sent me an extension to the example, but i think it is still not encompassing. b) Describe some details on how user space - kernel works probably using libnl?? I'll take care of that. Whats the plan? To add to this doc or separate doc? The status is that the code is there including userspace tools to query the controller. I have a patch for the controller for iproute2 that i would like to submit as well - but that is separate from this i think. Documentation is written as part of the API reference (coming up with -pre6), no architectural notes yet though. I think it's best to keep it separated and refer to it both ways. So you mean just refer to the one in the kernel headers? cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
* jamal [EMAIL PROTECTED] 2006-06-19 09:41
// the attributes you want to own
enum {
FOOBAR_ATTR_UNSPEC,
FOOBAR_ATTR_TYPE,
FOOBAR_ATTR_TYPEID,
FOOBAR_ATTR_TYPENAME,
FOOBAR_ATTR_OPER,
/* add future attributes here */
__FOOBAR_ATTR_MAX,
};
#define FOOBAR_ATTR_MAX (__FOOBAR_ATTR_MAX - 1)
One important point about attributes in generic netlink is that
their scope is per command instead of per family as in netlink.
It's not forbidden to use the same set of attribute identifiers
for two separete commands but it should be avoided to have a
single large list of attributes and have every command pick out
the attributes it needs.
TODO:
a) Add a more complete compiling kernel module with events.
Have Thomas put his Mashimaro example and point to it.
I guess we have a legal issue here ;)
b) Describe some details on how user space - kernel works
probably using libnl??
I'll take care of that.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
On Mon, 2006-19-06 at 11:58 -0400, Shailabh Nagar wrote: jamal wrote: [..] But I'm not too clear about what are the advantages of trying to limit the number of commands registered by a given exploiter of genetlink (say TIPC or taskstats), other than the conventional usage of netlink. e.g in the taskstats code, userspace needs to GET data on a per-pid and per-tgid basis from the kernel and supplies the specific pid or tgid. We could either have registered two commands (say GET_PID and GET_TGID) and then the parsing of the supplied uint32 would be implicit in the command. But we went with the model where we have only one GET command and the type of the parameter is specified via netlink attributes. The idea is for fine grain access control(ACL) of what user process can do (as managed by SELinux not genetlink). As an example even in your case, you may wanna allow user program shailab1 to be able to get information on a groupid but not pid. We should be able to add that level of granularity easily since we have flags per command. In our case, it didn't matter and since the type of data returned is very similar and so is the parameter supplied (pid/tgid), one GET suffices. But I'm wondering if userspace should consciously try and limit the commands or would it be better from a performance standpoint, to permit a reasonably larger fan-out to happen at the genetlink command level (for each exploiter). I guess this introduces more overhead for in-kernel structures (the linked list of command structures that needs to be kept around) while saving time on doing a second level of parsing within the exploiter-defined function that services the GET command. The small set model looks like a good compromise. Reducing number of commands to one is not a good idea IMHOfor reasons similar to why ioctl type syscalls aren't encouraged...since the genetlink layer anyway has code for demultiplexing, might as well use it and avoid an extra level of indirection. indeed. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
On Mon, 2006-19-06 at 18:37 -0400, Shailabh Nagar wrote: Completing the documentation on generic netlink usage will definitely be useful. I'd be happy to help out with this since I've recently gone through trying to understand and use genetlink for the taskstats interface. Hopefully this will help other users like me who aren't netlink experts to begin with ! Thanks - I really appreciate it. I've sent you a patch to the document that attempts to cover the following TODOS (didn't see any point sending it to the whole list since its harder to read patches to documentation). Pls use as you see fit. Ive received it and will respond to you privately. TODO: a) Add a more complete compiling kernel module with events. Have Thomas put his Mashimaro example and point to it. (not the Mashimaro example, nor a completly compiled module but snippets of pseudo code taken from the user space program used in taskstats development, modified to the foobar example you've used) Thomas had a more complete piece of code which exercised more paths. The document just has to point to where that code is. b) Describe some details on how user space - kernel works probably using libnl?? c) Describe discovery using the controller.. I'll provide another patch that will cover d) and e) in the set below, again in the context of the foobar example, which might need to be modified a bit. no problem. go nuts. d) talk about policies etc e) talk about how something coming from user space eventually gets to you. f) Talk about the TLV manipulation stuff from Thomas. g) submit controller patch to iproute2 One point...does d), f) etc. belong in a separate doc describing usage of netlink attributes ? Its useful here too but not directly related to genetlink perhaps. My thought was to provide a one-stop shop; however, it may be a separate doc or incorporated in this and referenced by it. PS:- I dont have a good place to put this doc and point to, hence the 17K attachment http://www.kernel.org/pub/linux/kernel/people/hadi/ ? (unless your permissions have been revoked for lack of use ! :-) I am only allowed to put kernel patches there by the powers that be. So this wont fit the criteria. It is hard to believe in these times my ISP charges me $1/M/month every time i exceed my allocated 5M quota. I have been with this ISP for 10 years, hence migration gets harder - and given that many years on the same account, even my .bashrc approaches 5M ;- cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
On Tue, 2006-20-06 at 10:02 +0200, Thomas Graf wrote: * jamal [EMAIL PROTECTED] 2006-06-19 09:41 One important point about attributes in generic netlink is that their scope is per command instead of per family as in netlink. It's not forbidden to use the same set of attribute identifiers for two separete commands but it should be avoided to have a single large list of attributes and have every command pick out the attributes it needs. Thanks - I will add this to the doc. Additionally the commands are scoped per registered family (as opposed of needing them to be encapsulated in the nlmsg_type). TODO: a) Add a more complete compiling kernel module with events. Have Thomas put his Mashimaro example and point to it. I guess we have a legal issue here ;) change the name ;- b) Describe some details on how user space - kernel works probably using libnl?? I'll take care of that. Whats the plan? To add to this doc or separate doc? cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
Hello TODO: a) Add a more complete compiling kernel module with events. Have Thomas put his Mashimaro example and point to it. I guess we have a legal issue here ;) change the name ;- Ask Mr. Mashimaro has become my replacement for 8ball. Renaming it would lead to a serious loss of coolness ;-) b) Describe some details on how user space - kernel works probably using libnl?? I'll take care of that. Whats the plan? To add to this doc or separate doc? The status is that the code is there including userspace tools to query the controller. Documentation is written as part of the API reference (coming up with -pre6), no architectural notes yet though. I think it's best to keep it separated and refer to it both ways. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[DOC]: generic netlink
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. The doc has been around for a while, i spent part of yesterday and this morning cleaning it up. If you have sent me comments before, please forgive me for having misplaced them - just send again. cheers, jamal PS:- I dont have a good place to put this doc and point to, hence the 17K attachment 1.0 Problem Statement --- Netlink is a robust wire-format IPC typically used for kernel-user communication although could also be used to be a communication carrier between user-user and kernel-kernel. A typical netlink connection setup is of the form: netlink_socket = socket(PF_NETLINK, socket_type, netlink_family); where netlink_family selects the netlink bus to communicate on. Example of a family would be NETLINK_ROUTE which is 0x0 or NETLINK_XFRM which is 0x6. [Refer to RFC 3549 for a high level view and look at include/linux/netlink.h for some of the allocated families]. Over the years, due to its robust design, netlink has become very popular. This has resulted in the danger of running out of family numbers to issue. In netconf 2005 in Montreal it was decided to find ways to work around the allocation challenge and as a result NETLINK_GENERIC bus was born. This document gives a mid-level view if NETLINK_GENERIC and how to use it. The reader does not necessarily have to know what netlink is, but needs to know at least the encapsulation used - which is described in the next section. There are some implicit assumptions about what netlink is or what structures like TLVs are etc. I apologize i dont have much time to give a tutorial - invite me to some odd conference and i will be forced to do better than this doc. Better send patches to this doc. 2.0 High Level view In order to illustrate the way different components talk to each other, the diagram below is used to provide an abstraction on how the operations happen. There are two (three depending on your perspective) components: 1) The generic netlink connection which for illustration is refered to as a bus. The generic netlink bus is shown as split between user and kernel domains: This means programs can connect to the bus from either kernel or user space. 2) components that talk to each other after attaching to the bus. a) Two users are shown in user spaces b)3 in the kernel. All boxes have kernel-wide unique identifiers that can be used to address them. Typicaly, user space boxes exist to control one or more kernel level boxen i.e they update some attributes that exist in a kernel level box. Any of these boxes can communicate to each other by first connecting to the bus and then sending messages addressed to any box. +--+ +--+ | user1 | .. | user-n | +--+---+ +---+--+ | | / | | |User +-++-+ Space/domain user || + Generic Netlink Bus +--- kernel || Kernel +--+--+--+ Space/domain || | || | || | || | +--+---++---+-+ +--+-+ |controller|| foobar | | googah | +--++-+ ++ The controller is a speacial built-in user of the bus. It is the repository of info on kernel components that have attached to the bus. It has a reserved address identifier of 0x10. By querying the controller, one could find out that both foobar and googah are registered and what their IDs are etc. Essentially its a namespace translator not unlike DNS is for IP addresses. More later on this. To get to the point of the most common usage of netlink (user space control of a kernel component), the diagram below breaks things down for a single user program that controls a kernel module called foobar. The example is simple for illustration purposes; as an example, user space could control a lot more kernel modules. +--+ | | |user program | gnl events ; ---| | (2),-/ +--^-+--^--+ ,' gnl| ^ foobar ^ foobar ,'discovery ^ | events | config/query ,' (1) | ^ (4) ^ (3) +--/--
Re: [DOC]: generic netlink
On Mon, 19 Jun 2006, jamal wrote: 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. Thanks for writing this up. It seems that TIPC is multiplexing all of it's commands through TIPC_GENL_CMD. I wonder, if this is how other protocols are likely to utilize genl, then we could possibly drop the command registration code completely and one command op can be registered by the protocol during genl_register_family(). This would both simplify the genl code and API, and help ensure consistency of users. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
On Mon, 2006-19-06 at 11:13 -0400, James Morris wrote: It seems that TIPC is multiplexing all of it's commands through TIPC_GENL_CMD. TIPC is a deviation; they had the 100 ioctls and therefore did a direct one-to-one mapping. I wonder, if this is how other protocols are likely to utilize genl, then we could possibly drop the command registration code completely and one command op can be registered by the protocol during genl_register_family(). The intent is to have a handful of commands as in classical netlink (eg route or qdisc etc) where you are controlling data that sits in the kernel; i.e when you have an attribute or a vector of attributes, then the commands will be of the semantics: ADD/DEL/GET/DUMP only. Other that TIPC the two other users i have seen use it in this manner. But, you are right if usage tends to lean in some other way we could get rid of it (I think TIPC is a bad example). This would both simplify the genl code and API, and help ensure consistency of users. You are talking from an SELinux perspective i take it? My view: If you want to have ACLs against such commands then it becomes easier to say can only do ADD but not DEL for example (We need to resolve genl_rcv_msg() check on commands to be in sync with SELinux as was pointed by Thomas) cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
On Mon, 19 Jun 2006, jamal wrote:
Other that TIPC the two other users i have seen use it in this manner.
But, you are right if usage tends to lean in some other way we could get
rid of it (I think TIPC is a bad example).
Ok, perhaps make a note in the docs about this and keep an eye out when
new code is submitted, and encourage people not to do this.
This would both simplify the genl code and API, and help ensure
consistency of users.
You are talking from an SELinux perspective i take it?
Actually, what would help SELinux is the opposite, forcing everyone to use
separate commands and assigning security attributes to each one. But
because TIPC is already multiplexing, it's not feasible.
Instead, I think the way to go for SELinux is to have each nl family
provide a permission callback, so SELinux can pass the skb back to the nl
module which then returns a type of permission ('read', 'write',
'readpriv'). This way, the nl module can create and manage its own
internal table of command permissions and also know exactly where in the
message to dig for the command specifier.
My view: If you want to have ACLs against such commands then it becomes
easier to say can only do ADD but not DEL for example (We need to
resolve genl_rcv_msg() check on commands to be in sync with SELinux as
was pointed by Thomas)
This already exists, to some extent, but only for some protocols. You can
see examples of existing permission tables managed by SELinux in:
security/selinux/nlmsgtab.c
The hope move this out of SELinux and into each nl module, which is much
more manageable and scalable.
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
jamal wrote: On Mon, 2006-19-06 at 11:13 -0400, James Morris wrote: It seems that TIPC is multiplexing all of it's commands through TIPC_GENL_CMD. TIPC is a deviation; they had the 100 ioctls and therefore did a direct one-to-one mapping. I wonder, if this is how other protocols are likely to utilize genl, then we could possibly drop the command registration code completely and one command op can be registered by the protocol during genl_register_family(). The intent is to have a handful of commands as in classical netlink (eg route or qdisc etc) where you are controlling data that sits in the kernel; i.e when you have an attribute or a vector of attributes, then the commands will be of the semantics: ADD/DEL/GET/DUMP only. Other that TIPC the two other users i have seen use it in this manner. But, you are right if usage tends to lean in some other way we could get rid of it (I think TIPC is a bad example). The taskstats interface, currently in -mm, is one user of genetlink http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/per-task-delay-accounting-taskstats-interface.patch Based on Jamal's suggestions, we found it useful to have the limited set of commands model and ended up with having to register just one GET command. And in subsequent discussions, a SET command would also be handy. But I'm not too clear about what are the advantages of trying to limit the number of commands registered by a given exploiter of genetlink (say TIPC or taskstats), other than the conventional usage of netlink. e.g in the taskstats code, userspace needs to GET data on a per-pid and per-tgid basis from the kernel and supplies the specific pid or tgid. We could either have registered two commands (say GET_PID and GET_TGID) and then the parsing of the supplied uint32 would be implicit in the command. But we went with the model where we have only one GET command and the type of the parameter is specified via netlink attributes. In our case, it didn't matter and since the type of data returned is very similar and so is the parameter supplied (pid/tgid), one GET suffices. But I'm wondering if userspace should consciously try and limit the commands or would it be better from a performance standpoint, to permit a reasonably larger fan-out to happen at the genetlink command level (for each exploiter). I guess this introduces more overhead for in-kernel structures (the linked list of command structures that needs to be kept around) while saving time on doing a second level of parsing within the exploiter-defined function that services the GET command. The small set model looks like a good compromise. Reducing number of commands to one is not a good idea IMHOfor reasons similar to why ioctl type syscalls aren't encouraged...since the genetlink layer anyway has code for demultiplexing, might as well use it and avoid an extra level of indirection. --Shailabh This would both simplify the genl code and API, and help ensure consistency of users. You are talking from an SELinux perspective i take it? My view: If you want to have ACLs against such commands then it becomes easier to say can only do ADD but not DEL for example (We need to resolve genl_rcv_msg() check on commands to be in sync with SELinux as was pointed by Thomas) cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
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. The doc has been around for a while, i spent part of yesterday and this morning cleaning it up. If you have sent me comments before, please forgive me for having misplaced them - just send again. Jamal, Completing the documentation on generic netlink usage will definitely be useful. I'd be happy to help out with this since I've recently gone through trying to understand and use genetlink for the taskstats interface. Hopefully this will help other users like me who aren't netlink experts to begin with ! I've sent you a patch to the document that attempts to cover the following TODOS (didn't see any point sending it to the whole list since its harder to read patches to documentation). Pls use as you see fit. TODO: a) Add a more complete compiling kernel module with events. Have Thomas put his Mashimaro example and point to it. (not the Mashimaro example, nor a completly compiled module but snippets of pseudo code taken from the user space program used in taskstats development, modified to the foobar example you've used) b) Describe some details on how user space - kernel works probably using libnl?? c) Describe discovery using the controller.. I'll provide another patch that will cover d) and e) in the set below, again in the context of the foobar example, which might need to be modified a bit. d) talk about policies etc e) talk about how something coming from user space eventually gets to you. f) Talk about the TLV manipulation stuff from Thomas. g) submit controller patch to iproute2 One point...does d), f) etc. belong in a separate doc describing usage of netlink attributes ? Its useful here too but not directly related to genetlink perhaps. PS:- I dont have a good place to put this doc and point to, hence the 17K attachment http://www.kernel.org/pub/linux/kernel/people/hadi/ ? (unless your permissions have been revoked for lack of use ! :-) Having the current document will be useful to see what edits have been accepted and work on that instead of the original. --Shailabh - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
