Hi Randy: Congratulations on finally being able to get Nortel's blessing to publish stuff! It'll be interesting to see how much of a response you get from the Linux kernel folks. I suspect it will either be: a) dead silence -- since it doesn't impact regular IP networking -- or, b) a gigantic flame telling you that the whole approach is wrong! In many ways, it would be better to see b) than a) ...
BTW, you might want to take a look at the changes that have been made in 2.6.24 (at least to David Miller's tree, anyway) that add the concept of "networking naming" to the socket API. I really don't know much about this, since I only had time to verify that the addition of a new parameter to tipc_create() was done correctly. This could be an alternative way of indicating to TIPC which network you want a socket to participate in. It might also shed some light on whether the "base module plus stack modules" idea is going to be acceptable to the Linux kernel community. Apologies for not suggesting this earlier; sometimes it takes a while to make a connection that later seems obvious ... Regards, Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Macleod Sent: Friday, January 11, 2008 2:43 PM To: [EMAIL PROTECTED] Cc: Chris Friesen; tipc; Ravik Rao Subject: [tipc-discussion] RFC: TIPC API, bind to two networks I'd like some feedback on a change to TIPC that I plan to submit to netdev/kernel.org. At this stage, I'm interested in what people think about using the protocol parameter of the socket interface to select a TIPC stack for the socket. My co-worker, Chris Friesen, has suggested that it would be more conventional to extend the TIPC sockaddr to select the appropriate network in calls to sendto() or bind(). I prefer socket(,,protocol) approach. Some background: We use TIPC in an ATCA chassis (Advanced Telecommunications Computing Architecture). An ATCA chassis may have two networks commonly called base and data (outside of the ATCA world base is called control). Users want to be able to create a TIPC socket that is bound to one network OR the other. The intention is that these networks should be isolated as much as possible. The attached patch accomplishes this by using the protocol parameter of the socket() syscall. A user can specify the TIPC stack to which the socket should be attached as follows: int socket(int domain, int type, int protocol); fd = socket(AF_TIPC, SOCK_SEQPACKET, 1); In the unpatched TIPC code the protocol was required to be zero. This requires that the user know the network topology or that the system designer provide an API (get_base_netid(), get_data_netid()). The patch is for tipc-1.5.12 which you can get from tipc.sf.net. We're way back on linux-2.6.14 - gotta love the embedded world! In terms of implementation, the basic idea of the patch is to introduce a layer in the TIPC code around socket creation and tipc netlink messages. This layer lets TIPC stack code register callback functions and then dispatches socket() and netlink calls to the appropriate TIPC stack. For example usage, please see: <http://sourceforge.net/mailarchive/message.php?msg_name=476839F3.807020 3%40nortel.com> One note for those who might not read the link above.... I create two modules: tipc.ko and tipcstack.ko these are ~98% identical with certain bits of functionality, like registering AF_TIPC, disabled. This means that we have the same bits of code loaded twice but that's a feature not a bug! It means that the control and data networks are even more independent so you could update one but not the other or you could use system tap on one but not the other. diffstat: Makefile | 15 +++- include/net/tipc/tipc.h | 11 ++- net/tipc/core.c | 157 +++++++++++++++++++++++------------------------- net/tipc/core.h | 25 +++++++ net/tipc/handler.c | 17 +++-- net/tipc/netlink.c | 21 +++++- net/tipc/socket.c | 55 ++++++++++++---- net/tipc/vtipc.c | 154 +++++++++++++++++++++++++++++++++++++++++++++++ net/tipc/vtipc.h | 48 ++++++++++++++ tools/tipc-config.c | 29 ++++++-- Even though I *don't* want the attached patch to be integrated into the kernel (yet), I'm still going to include: Signed-off-by: Randy MacLeod ([EMAIL PROTECTED]) because it's taken such a long time to get Nortel to bless official kernel participation! // Randy ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
