Re: [tipc-discussion] [RFC: 2.6 patch] net/tipc/: possible cleanups
On Sat, Feb 24, 2007 at 04:19:19PM -0800, Stephens, Allan wrote: ... 2) There are portions of TIPC's native API which are intended for use by driver programmers, but which are not being used by any code that is currently in the kernel. While removing these API's from TIPC will only impact these freeloaders, it has the potential to discourage future programmers who *do* want to contribute their work to the kernel by removing API's that are apparently necessary/useful when doing coding of this sort. It can be re-added at any time when an in-kernel user comes. But the most interesting question is: Why is noone interested in getting his TIPC using drivers merged? Regards, Al ... cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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
SV: Re: [tipc-discussion] [RFC: 2.6 patch] net/tipc/: possible cleanups
--- Adrian Bunk [EMAIL PROTECTED] skrev: It can be re-added at any time when an in-kernel user comes. But the most interesting question is: Why is noone interested in getting his TIPC using drivers merged? I don't think lack of interest is the issue here. The users I know anything about, would be both happy and proud to contribute code to the main tree. One I know about,who has developed a very interesting reliable bond interface based on this API, doesn't regard his code to be up to the kernel coding standards yet, although I am trying to encourage him. Another one thinks his function is just too specialized to be of any common interest. In the future, I would be also be very interested in seeing a cross-node netlink implementation, carried over TIPC, using this API. (Unfortunately, I don't dare to commit to this myself right now, there is too much left to be done in TIPC.) So, as you see, keeping the exported symbols would be a definite advantage, as current and future developers would not have to patch the kernel to do their work. Regards ///jon - 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: [tipc-discussion] [RFC: 2.6 patch] net/tipc/: possible cleanups
Just to clarify an apparent misunderstanding that has snuck into this thread: 1) There are quite a few people/groups out there who are using TIPC's socket API, so the protocol as a whole is being used and should remain in the kernel. 2) There are portions of TIPC's native API which are intended for use by driver programmers, but which are not being used by any code that is currently in the kernel. While removing these API's from TIPC will only impact these freeloaders, it has the potential to discourage future programmers who *do* want to contribute their work to the kernel by removing API's that are apparently necessary/useful when doing coding of this sort. Regards, Al -Original Message- From: Christoph Hellwig [mailto:[EMAIL PROTECTED] Sent: Friday, February 23, 2007 5:17 PM To: Adrian Bunk Cc: Jon Maloy; [EMAIL PROTECTED]; Stephens, Allan; netdev@vger.kernel.org; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Re: [tipc-discussion] [RFC: 2.6 patch] net/tipc/: possible cleanups On Fri, Feb 23, 2007 at 07:06:12PM +0100, Adrian Bunk wrote: My impression is that most of this might have users that are not yet submitted for inclusion in the kernel - one year after TIPC was merged. Not quite. The exported symbols belong to a public API for driver programmers. We know about several users of this API, and there will be more, but I don't think any of them are aspiring to have their code be included in the kernel. ... Why not? The goal is to get as many drivers as possible included in the kernel. If we don't have any planned in-tree users for tipc we should simply drop tipc from the kernel entirely. No point to make our maintaince work harder for out of tree freeloaders. - 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: [tipc-discussion] [RFC: 2.6 patch] net/tipc/: possible cleanups
On Thu, Jan 25, 2007 at 04:08:08PM +, Jon Maloy wrote: Adrian Bunk wrote: This patch contains the following possible cleanups: - make needlessly global functions static - #if 0 unused functions Thanks. I think most of those were due for our next release, anyway. But we'll get it in, one way or another. - remove all EXPORT_SYMBOL's My impression is that most of this might have users that are not yet submitted for inclusion in the kernel - one year after TIPC was merged. Not quite. The exported symbols belong to a public API for driver programmers. We know about several users of this API, and there will be more, but I don't think any of them are aspiring to have their code be included in the kernel. ... Why not? The goal is to get as many drivers as possible included in the kernel. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: [tipc-discussion] [RFC: 2.6 patch] net/tipc/: possible cleanups
On Fri, Feb 23, 2007 at 07:06:12PM +0100, Adrian Bunk wrote: My impression is that most of this might have users that are not yet submitted for inclusion in the kernel - one year after TIPC was merged. Not quite. The exported symbols belong to a public API for driver programmers. We know about several users of this API, and there will be more, but I don't think any of them are aspiring to have their code be included in the kernel. ... Why not? The goal is to get as many drivers as possible included in the kernel. If we don't have any planned in-tree users for tipc we should simply drop tipc from the kernel entirely. No point to make our maintaince work harder for out of tree freeloaders. - 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: [tipc-discussion] [RFC: 2.6 patch] net/tipc/: possible cleanups
Adrian Bunk wrote: This patch contains the following possible cleanups: - make needlessly global functions static - #if 0 unused functions Thanks. I think most of those were due for our next release, anyway. But we'll get it in, one way or another. - remove all EXPORT_SYMBOL's My impression is that most of this might have users that are not yet submitted for inclusion in the kernel - one year after TIPC was merged. Not quite. The exported symbols belong to a public API for driver programmers. We know about several users of this API, and there will be more, but I don't think any of them are aspiring to have their code be included in the kernel. If this is true, please submit the users for inclusion in the kernel. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- include/net/tipc/tipc.h | 60 include/net/tipc/tipc_port.h |9 net/tipc/addr.c |2 net/tipc/cluster.c |2 net/tipc/cluster.h |1 net/tipc/config.c|9 +++- net/tipc/config.h|7 --- net/tipc/core.c | 74 ++- net/tipc/core.h | 14 -- net/tipc/dbg.c | 15 +-- net/tipc/dbg.h |3 - net/tipc/discover.c |4 + net/tipc/discover.h |1 net/tipc/link.c | 14 +++--- net/tipc/link.h |4 - net/tipc/name_table.c|3 - net/tipc/node.c |6 +- net/tipc/node.h |1 net/tipc/port.c | 59 +-- net/tipc/port.h |2 net/tipc/subscr.c|2 net/tipc/zone.c |2 net/tipc/zone.h |1 23 files changed, 97 insertions(+), 198 deletions(-) --- linux-2.6.20-rc4-mm1/include/net/tipc/tipc.h.old2007-01-24 19:12:15.0 +0100 +++ linux-2.6.20-rc4-mm1/include/net/tipc/tipc.h2007-01-24 20:40:58.0 +0100 @@ -50,8 +50,6 @@ * TIPC operating mode routines */ -u32 tipc_get_addr(void); - #define TIPC_NOT_RUNNING 0 #define TIPC_NODE_MODE1 #define TIPC_NET_MODE 2 @@ -62,8 +60,6 @@ void tipc_detach(unsigned int userref); -int tipc_get_mode(void); - /* * TIPC port manipulation routines */ @@ -153,12 +149,8 @@ int tipc_shutdown(u32 ref); /* Sends SHUTDOWN msg */ -int tipc_isconnected(u32 portref, int *isconnected); - int tipc_peer(u32 portref, struct tipc_portid *peer); -int tipc_ref_valid(u32 portref); - /* * TIPC messaging routines */ @@ -170,38 +162,12 @@ unsigned int num_sect, struct iovec const *msg_sect); -int tipc_send_buf(u32 portref, - struct sk_buff *buf, - unsigned int dsz); - int tipc_send2name(u32 portref, struct tipc_name const *name, u32 domain, /* 0:own zone */ unsigned int num_sect, struct iovec const *msg_sect); -int tipc_send_buf2name(u32 portref, - struct tipc_name const *name, - u32 domain, - struct sk_buff *buf, - unsigned int dsz); - -int tipc_forward2name(u32 portref, - struct tipc_name const *name, - u32 domain, /*0: own zone */ - unsigned int section_count, - struct iovec const *msg_sect, - struct tipc_portid const *origin, - unsigned int importance); - -int tipc_forward_buf2name(u32 portref, - struct tipc_name const *name, - u32 domain, - struct sk_buff *buf, - unsigned int dsz, - struct tipc_portid const *orig, - unsigned int importance); - int tipc_send2port(u32 portref, struct tipc_portid const *dest, unsigned int num_sect, @@ -212,20 +178,6 @@ struct sk_buff *buf, unsigned int dsz); -int tipc_forward2port(u32 portref, - struct tipc_portid const *dest, - unsigned int num_sect, - struct iovec const *msg_sect, - struct tipc_portid const *origin, - unsigned int importance); - -int tipc_forward_buf2port(u32 portref, - struct tipc_portid const *dest, - struct sk_buff *buf, - unsigned int dsz, - struct tipc_portid const *orig, - unsigned int importance); - int tipc_multicast(u32 portref, struct tipc_name_seq const *seq, u32 domain, /* 0:own zone */ @@ -240,18 +192,6 @@ unsigned int size); #endif -/* - * TIPC subscription routines - */ - -int tipc_ispublished(struct tipc_name const *name); - -/* - * Get number of available nodes
[RFC: 2.6 patch] net/tipc/: possible cleanups
This patch contains the following possible cleanups: - make needlessly global functions static - #if 0 unused functions - remove all EXPORT_SYMBOL's My impression is that most of this might have users that are not yet submitted for inclusion in the kernel - one year after TIPC was merged. If this is true, please submit the users for inclusion in the kernel. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- include/net/tipc/tipc.h | 60 include/net/tipc/tipc_port.h |9 net/tipc/addr.c |2 net/tipc/cluster.c |2 net/tipc/cluster.h |1 net/tipc/config.c|9 +++- net/tipc/config.h|7 --- net/tipc/core.c | 74 ++- net/tipc/core.h | 14 -- net/tipc/dbg.c | 15 +-- net/tipc/dbg.h |3 - net/tipc/discover.c |4 + net/tipc/discover.h |1 net/tipc/link.c | 14 +++--- net/tipc/link.h |4 - net/tipc/name_table.c|3 - net/tipc/node.c |6 +- net/tipc/node.h |1 net/tipc/port.c | 59 +-- net/tipc/port.h |2 net/tipc/subscr.c|2 net/tipc/zone.c |2 net/tipc/zone.h |1 23 files changed, 97 insertions(+), 198 deletions(-) --- linux-2.6.20-rc4-mm1/include/net/tipc/tipc.h.old2007-01-24 19:12:15.0 +0100 +++ linux-2.6.20-rc4-mm1/include/net/tipc/tipc.h2007-01-24 20:40:58.0 +0100 @@ -50,8 +50,6 @@ * TIPC operating mode routines */ -u32 tipc_get_addr(void); - #define TIPC_NOT_RUNNING 0 #define TIPC_NODE_MODE1 #define TIPC_NET_MODE 2 @@ -62,8 +60,6 @@ void tipc_detach(unsigned int userref); -int tipc_get_mode(void); - /* * TIPC port manipulation routines */ @@ -153,12 +149,8 @@ int tipc_shutdown(u32 ref); /* Sends SHUTDOWN msg */ -int tipc_isconnected(u32 portref, int *isconnected); - int tipc_peer(u32 portref, struct tipc_portid *peer); -int tipc_ref_valid(u32 portref); - /* * TIPC messaging routines */ @@ -170,38 +162,12 @@ unsigned int num_sect, struct iovec const *msg_sect); -int tipc_send_buf(u32 portref, - struct sk_buff *buf, - unsigned int dsz); - int tipc_send2name(u32 portref, struct tipc_name const *name, u32 domain, /* 0:own zone */ unsigned int num_sect, struct iovec const *msg_sect); -int tipc_send_buf2name(u32 portref, - struct tipc_name const *name, - u32 domain, - struct sk_buff *buf, - unsigned int dsz); - -int tipc_forward2name(u32 portref, - struct tipc_name const *name, - u32 domain, /*0: own zone */ - unsigned int section_count, - struct iovec const *msg_sect, - struct tipc_portid const *origin, - unsigned int importance); - -int tipc_forward_buf2name(u32 portref, - struct tipc_name const *name, - u32 domain, - struct sk_buff *buf, - unsigned int dsz, - struct tipc_portid const *orig, - unsigned int importance); - int tipc_send2port(u32 portref, struct tipc_portid const *dest, unsigned int num_sect, @@ -212,20 +178,6 @@ struct sk_buff *buf, unsigned int dsz); -int tipc_forward2port(u32 portref, - struct tipc_portid const *dest, - unsigned int num_sect, - struct iovec const *msg_sect, - struct tipc_portid const *origin, - unsigned int importance); - -int tipc_forward_buf2port(u32 portref, - struct tipc_portid const *dest, - struct sk_buff *buf, - unsigned int dsz, - struct tipc_portid const *orig, - unsigned int importance); - int tipc_multicast(u32 portref, struct tipc_name_seq const *seq, u32 domain, /* 0:own zone */ @@ -240,18 +192,6 @@ unsigned int size); #endif -/* - * TIPC subscription routines - */ - -int tipc_ispublished(struct tipc_name const *name); - -/* - * Get number of available nodes within specified domain (excluding own node) - */ - -unsigned int tipc_available_nodes(const u32 domain); - #endif #endif --- linux-2.6.20-rc4-mm1/net/tipc/addr.c.old2007-01-24 19:12:34.0 +0100 +++
