tipc-discussion — User questions & problem reports, project news, developer discussion

[Tipc-discussion] linux-2.6 socket.c

[Mark H. <ma...@os...>]

The net_proto_ops and the net_proto_family structures don't set the
owner field.  This prevents proper reference counting for the module and
allows the module to be unloaded when in use.  This diff initialized the
owner field and also converts the initialization to the style used by
the kernel code.

Any objections to checking this in?

Mark.

--- /home/markh/views/tipc/cvs/source/unstable/net/tipc/linux-2.6/socket.c	2004-03-30 07:11:39.000000000 -0800
+++ socket.c	2004-04-13 13:14:06.000000000 -0700
@@ -1352,69 +1352,73 @@
 }
 
 static struct proto_ops msg_ops = {
-	family:AF_TIPC,
-	release:release,
-	bind:bind,
-	connect:connect,
-	socketpair:no_skpair,
-	accept:accept,
-	getname:get_name,
-	poll:poll,
-	ioctl:ioctl,
-	listen:listen,
-	shutdown:shutdown,
-	setsockopt:setsockopt,
-	getsockopt:getsockopt,
-	sendmsg:send_msg,
-	recvmsg:recv_msg,
-        mmap:no_mmap,
-        sendpage:no_sendpage
+	.owner 		= THIS_MODULE,
+	.family		= AF_TIPC,
+	.release	= release,
+	.bind		= bind,
+	.connect	= connect,
+	.socketpair	= no_skpair,
+	.accept		= accept,
+	.getname	= get_name,
+	.poll		= poll,
+	.ioctl		= ioctl,
+	.listen		= listen,
+	.shutdown	= shutdown,
+	.setsockopt	= setsockopt,
+	.getsockopt	= getsockopt,
+	.sendmsg	= send_msg,
+	.recvmsg	= recv_msg,
+        .mmap		= no_mmap,
+        .sendpage	= no_sendpage
 };
 
 static struct proto_ops packet_ops = {
-	family:AF_TIPC,
-	release:release,
-	bind:bind,
-	connect:connect,
-	socketpair:no_skpair,
-	accept:accept,
-	getname:get_name,
-	poll:poll,
-	ioctl:ioctl,
-	listen:listen,
-	shutdown:shutdown,
-	setsockopt:setsockopt,
-	getsockopt:getsockopt,
-	sendmsg:send_packet,
-	recvmsg:recv_msg,
-        mmap:no_mmap,
-        sendpage:no_sendpage
+	.owner 		= THIS_MODULE,
+	.family		= AF_TIPC,
+	.release	= release,
+	.bind		= bind,
+	.connect	= connect,
+	.socketpair	= no_skpair,
+	.accept		= accept,
+	.getname	= get_name,
+	.poll		= poll,
+	.ioctl		= ioctl,
+	.listen		= listen,
+	.shutdown	= shutdown,
+	.setsockopt	= setsockopt,
+	.getsockopt	= getsockopt,
+	.sendmsg	= send_packet,
+	.recvmsg	= recv_msg,
+        .mmap		= no_mmap,
+        .sendpage	= no_sendpage
 };
 
 static struct proto_ops stream_ops = {
-	family:AF_TIPC,
-	release:release,
-	bind:bind,
-	connect:connect,
-	socketpair:no_skpair,
-	accept:accept,
-	getname:get_name,
-	poll:poll,
-	ioctl:ioctl,
-	listen:listen,
-	shutdown:shutdown,
-	setsockopt:setsockopt,
-	getsockopt:getsockopt,
-	sendmsg:send_stream,
-	recvmsg:recv_stream,
-        mmap:no_mmap,
-        sendpage:no_sendpage
+	.owner 		= THIS_MODULE,
+	.family		= AF_TIPC,
+	.release	= release,
+	.bind		= bind,
+	.connect	= connect,
+	.socketpair	= no_skpair,
+	.accept		= accept,
+	.getname	= get_name,
+	.poll		= poll,
+	.ioctl		= ioctl,
+	.listen		= listen,
+	.shutdown	= shutdown,
+	.setsockopt	= setsockopt,
+	.getsockopt	= getsockopt,
+	.sendmsg	= send_stream,
+	.recvmsg	= recv_stream,
+        .mmap		= no_mmap,
+        .sendpage	= no_sendpage
 };
 
 
 static struct net_proto_family tipc_family_ops = {
-	family:AF_TIPC,
-	create:tipc_socket
+	.owner 		= THIS_MODULE,
+	.family		= AF_TIPC,
+	.create		= tipc_socket
 };
 
 int

-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] RE: tipc socket types

[Mark H. <ma...@os...>]

On Sat, 2004-04-10 at 11:25, Jon Maloy (QB/EMC) wrote:
> SOCK_RDM is for connectionless communication (using tipc_name
> or tipc_portid as explicit ddesses). This communication mode
> is reliable, unless you set the "unreliable" option, in which
> case it becomes an equivalent to SOCK_DGRAM, i.e. unreliable
> connectionless communication.
> 
> SOCK_SEQPACKET is for connection oriented, message based 
> communication. Acoording to POSIX this mode should be reliable,
> and it is, but a peculiarity with TIPC is that it is possible
> to make it unreliable, using the "unreliable" otion. When
> this option is set, messages will be discarded during congestion
> or overload, instead of being returned to sender, which is the
> old (and default) behaviour.
> 
> SOCK_STREAM is connection and stream oriented, just lik TCP.
> It is meant to partially emulate the behaviour of TCP, but
> it obeys to only a fraction of the usual TCP options, simply
> because those are irrelevent to TIPC. This socket type can
> not be made unreliable.
> 
> Regards /Jon

Thanks,  that helps a lot.

Mark.


> 
> -----Original Message-----
> From: Mark Haverkamp
> To: Jon Maloy (QB/EMC)
> Cc: tipc
> Sent: 09.04.2004 12:51
> Subject: tipc socket types
> 
> 
> I have been noticing that tipc now supports a number of socket types
> when creating a socket.  I have been used to the old tipc that the
> socket type didn't matter.  I have found, for instance, that the only
> socket type that I can do multiple sento calls on is SOCK_RDM.  Could
> you discuss the different socket types supported and how they work in
> tipc?
> 
> Thanks,
> Mark.
> -- 
> Mark Haverkamp <ma...@os...>
-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] RE: tipc socket types

[Jon M. (QB/EMC) <jon...@er...>]

SOCK_RDM is for connectionless communication (using tipc_name
or tipc_portid as explicit ddesses). This communication mode
is reliable, unless you set the "unreliable" option, in which
case it becomes an equivalent to SOCK_DGRAM, i.e. unreliable
connectionless communication.

SOCK_SEQPACKET is for connection oriented, message based 
communication. Acoording to POSIX this mode should be reliable,
and it is, but a peculiarity with TIPC is that it is possible
to make it unreliable, using the "unreliable" otion. When
this option is set, messages will be discarded during congestion
or overload, instead of being returned to sender, which is the
old (and default) behaviour.

SOCK_STREAM is connection and stream oriented, just lik TCP.
It is meant to partially emulate the behaviour of TCP, but
it obeys to only a fraction of the usual TCP options, simply
because those are irrelevent to TIPC. This socket type can
not be made unreliable.

Regards /Jon

-----Original Message-----
From: Mark Haverkamp
To: Jon Maloy (QB/EMC)
Cc: tipc
Sent: 09.04.2004 12:51
Subject: tipc socket types


I have been noticing that tipc now supports a number of socket types
when creating a socket.  I have been used to the old tipc that the
socket type didn't matter.  I have found, for instance, that the only
socket type that I can do multiple sento calls on is SOCK_RDM.  Could
you discuss the different socket types supported and how they work in
tipc?

Thanks,
Mark.
-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] RE: Another tipc observation

[Jon M. (QB/EMC) <jon...@er...>]

Certainly not. I am surprised that it works at all,
given that the management code is not tested at all
yet. Feel free to correct it.

Thanks /Jon

-----Original Message-----
From: Mark Haverkamp
To: Jon Maloy (QB/EMC)
Cc: tipc
Sent: 09.04.2004 16:04
Subject: Another tipc observation

While running some more tests, I noticed that the TIPC_GET_NODES
management command doesn't return the node addresses in network order
like the old TIPC_GET_PROCESSORS command does.  Just curious if it is
supposed to be that way.

Mark.
-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] a couple tipc bug fixes.

[Mark H. <ma...@os...>]

I checked a couple bug fixes for management access into CVS.  The
attached diff show the changes.

I think that tipc_get_bearers is expected to return a size and
that mng_prepare_re_msg was treating rmsg as if it wasn't a pointer.

Mark.

--- media.c	2004-03-30 07:11:38.000000000 -0800
+++ /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/media.c	2004-04-09 14:06:09.000000000 -0700
@@ -518,7 +518,7 @@
 		media++;
 	}
         read_unlock_bh(&net_lock);
-	return TIPC_OK;
+	return buf.crs-raw;
 }
 
 
--- manager.c	2004-03-09 09:34:28.000000000 -0800
+++ /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/manager.c	2004-04-09 14:08:16.000000000 -0700
@@ -158,12 +158,12 @@
 			 const char* data,
 			 const uint size)
 {
-	memset(&rmsg, 0, sizeof (rmsg));
+	memset(rmsg, 0, sizeof (*rmsg));
 	rmsg->cmd = htonl(cmd);
 	rmsg->retval = htonl(res);
 	memcpy(rmsg->usr_handle,usr_handle,sizeof(rmsg->usr_handle));
 	rmsg->result_len = htonl(sizeof(rmsg->result));
-	sct[0].data = (const unchar *) &rmsg;
+	sct[0].data = (const unchar *) rmsg;
 	sct[0].size = sizeof(*rmsg);
 	if (!data)
 		return;

-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] Another tipc observation

[Mark H. <ma...@os...>]

While running some more tests, I noticed that the TIPC_GET_NODES
management command doesn't return the node addresses in network order
like the old TIPC_GET_PROCESSORS command does.  Just curious if it is
supposed to be that way.

Mark.
-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] tipc socket types

[Mark H. <ma...@os...>]

I have been noticing that tipc now supports a number of socket types
when creating a socket.  I have been used to the old tipc that the
socket type didn't matter.  I have found, for instance, that the only
socket type that I can do multiple sento calls on is SOCK_RDM.  Could
you discuss the different socket types supported and how they work in
tipc?

Thanks,
Mark.
-- 
Mark Haverkamp <ma...@os...>

Re: [Tipc-discussion] Tipc-discussion] Vairable Declaration Cleanup

[Mark H. <ma...@os...>]

On Thu, 2004-04-08 at 16:35, hek...@ya... wrote:
> Hello,
> 
> The following patch is some minor clean up for variable
> declaration to make TIPC compilable by some earlier version
> of gcc which requires all variable declarations are in 
> the beginning of a block.
> 
> Let me know if you have any concerns in this:
> 
> Thanks
> 


I noticed that these same files in linux-2.6 also have the same
problems.

Mark.

-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] Tipc-discussion] Vairable Declaration Cleanup

[<hek...@ya...>]

Hello,

The following patch is some minor clean up for variable
declaration to make TIPC compilable by some earlier version
of gcc which requires all variable declarations are in 
the beginning of a block.

Let me know if you have any concerns in this:

Thanks

Kevin

----------------------------------------

Index: proc.c
===================================================================
RCS file: /cvsroot/tipc/source/unstable/net/tipc/linux-2.4/proc.c,v
retrieving revision 1.1
diff -c -r1.1 proc.c
*** proc.c      27 Mar 2004 01:11:53 -0000      1.1
--- proc.c      8 Apr 2004 23:21:05 -0000
***************
*** 390,399 ****
  proc_nb_to_addr(int procNb)
  {
        int zone = procNb / MAX_PROCS_BY_SUBNET;
-       zone++;
        int processor = procNb % MAX_PROCS_BY_SUBNET;
-       processor++;
        tipc_ref_t ret;
        ret = (zone << 24) + (zone << 12) + processor;
        return ret;
  }
--- 390,399 ----
  proc_nb_to_addr(int procNb)
  {
        int zone = procNb / MAX_PROCS_BY_SUBNET;
        int processor = procNb % MAX_PROCS_BY_SUBNET;
        tipc_ref_t ret;
+       zone++;
+       processor++;
        ret = (zone << 24) + (zone << 12) + processor;
        return ret;
  }
***************
*** 1013,1018 ****
--- 1013,1019 ----
        tipc_ref_t *port_id = NULL;
        struct tipc_cmd_msg cmd_msg;
        struct tipc_msg_section msg;
+       struct tipc_get_name_table_argv name_table_argv;

        tipc_msg_event cb = NULL;
        //printk("manager2\n");
***************
*** 1064,1070 ****
                break;
        case (NAME_TABLE_TYPE):
                port_id = &port_id_name_table;
-               struct tipc_get_name_table_argv name_table_argv;
                name_table_argv.type = 0;
                name_table_argv.depth = htonl(value);   //only works for 0??
                cb = (tipc_msg_event) get_name_table_cb;
--- 1065,1070 ----
***************
*** 1660,1670 ****
  {

        struct proc_dir_entry *zoneTmpDir, *subnetTmpDir, *procTmpDir, *fileTmp;
!       int zone, proc, i;
        char name[LINK_NAME_LENGTH];
        zone = tipc_zone(addr) - 1;
        proc = tipc_node(addr) - 1;
!       int procNb = (zone * MAX_PROCS_BY_SUBNET) + proc;
        //proc already exists (should not happen, it's a security for integrity)
        if ((zones[zone] == 1) && (subnets[zone] != NULL)
            && (procs[procNb] != NULL)) {
--- 1660,1670 ----
  {

        struct proc_dir_entry *zoneTmpDir, *subnetTmpDir, *procTmpDir, *fileTmp;
!       int zone, proc, i, procNb;
        char name[LINK_NAME_LENGTH];
        zone = tipc_zone(addr) - 1;
        proc = tipc_node(addr) - 1;
!       procNb = (zone * MAX_PROCS_BY_SUBNET) + proc;
        //proc already exists (should not happen, it's a security for integrity)
        if ((zones[zone] == 1) && (subnets[zone] != NULL)
            && (procs[procNb] != NULL)) {
***************
*** 1752,1761 ****
  {

        char name[LINK_NAME_LENGTH];
!       int zone, proc, i, flag = 1;
        zone = tipc_zone(addr) - 1;
        proc = tipc_node(addr) - 1;
!       int procNb = (zone * MAX_PROCS_BY_SUBNET) + proc;
        //remove the specified processor
        if (procs[procNb] != NULL) {
                //free the LinkNames array of the processors and the Links Directory
--- 1752,1761 ----
  {

        char name[LINK_NAME_LENGTH];
!       int zone, proc, i, procNb, flag = 1;
        zone = tipc_zone(addr) - 1;
        proc = tipc_node(addr) - 1;
!       procNb = (zone * MAX_PROCS_BY_SUBNET) + proc;
        //remove the specified processor
        if (procs[procNb] != NULL) {
                //free the LinkNames array of the processors and the Links Directory
***************
*** 1917,1922 ****
--- 1917,1923 ----
        char cb_name[50] = { 0 };
        const char *cb_result = NULL;
        char *available;
+       char *bearer_name;

        char procResult[100] = { 0 };

***************
*** 1953,1959 ****
                sprintf(cb_name, "%s", "get_processors");
                proc_info = get_parent_proc_info(info->this, 1);
                //printk("procinfo.addr: %u\n", proc_info.proc_addr);
!               int ret =ask_manager_and_wait(PROCESSORS_TYPE, "get_processors",
                                         &get_processors_cb_done, 0, 0, NULL, 0);
                print_manager_return_value(ret, cb_name);
                if (ret != -1) {
--- 1954,1960 ----
                sprintf(cb_name, "%s", "get_processors");
                proc_info = get_parent_proc_info(info->this, 1);
                //printk("procinfo.addr: %u\n", proc_info.proc_addr);
!               ret =ask_manager_and_wait(PROCESSORS_TYPE, "get_processors",
                                         &get_processors_cb_done, 0, 0, NULL, 0);
                print_manager_return_value(ret, cb_name);
                if (ret != -1) {
***************
*** 2074,2080 ****
        case (DISABLE_BEARER_TYPE):
                sprintf(cb_name, "%s", "disable_bearer");
                proc_info = get_parent_proc_info(info->this, 4);
-               char *bearer_name;
                bearer_name = bearer_name_from_dir(info->this);
                ret =ask_manager_and_wait(DISABLE_BEARER_TYPE, cb_name, &second_cmd_group_cb_done,
1,
                                         proc_info.proc_addr, bearer_name, 0);
--- 2075,2080 ----
Index: udp_media.c
===================================================================
RCS file: /cvsroot/tipc/source/unstable/net/tipc/linux-2.4/udp_media.c,v
retrieving revision 1.1
diff -c -r1.1 udp_media.c
*** udp_media.c 27 Mar 2004 01:11:53 -0000      1.1
--- udp_media.c 8 Apr 2004 23:21:06 -0000
***************
*** 207,212 ****
--- 207,213 ----
        struct sockaddr_in t_addr;
        struct sock *sk;
        struct sockaddr_in l_addr;
+       struct net_device *dev;
        uint one = 1;
        mm_segment_t saved_addr = get_fs();
        b->usr_handle = &bearer;
***************
*** 281,287 ****
        if (udp0 >= TIPC_NODE_SCOPE)
                return 1;

!       struct net_device *dev = dev_base;
        while (dev) {
                struct ip_mreqn mreqn;
                mreqn.imr_multiaddr.s_addr =
--- 282,288 ----
        if (udp0 >= TIPC_NODE_SCOPE)
                return 1;

!       dev = dev_base;
        while (dev) {
                struct ip_mreqn mreqn;
                mreqn.imr_multiaddr.s_addr =

[Tipc-discussion] Non-blocking I/O Support Questions

[<all...@wi...>]

Hi there:
 
I've been looking at the code relating to non-blocking sockets in TIPC, and
it doesn't seem to be quite right to me.
 
Question 1: The ioctl() routine in socket.c is using F_SETFL and O_NONBLOCK
to enable the non-blocking capability.  Shouldn't it be using FIONBIO?
(F_SETFL and O_NONBLOCK are used with fcntl(), not ioctl(), as far as I
know.)
 
Question 2: The implementation of ioctl() allows you to make a socket
non-blocking, but not to revert it back to blocking.  Is there a reason this
is not provided?
 
Question 3: Why is there a TIPC-specific socket option called
O_NONBLOCK_OPTION?  This seems to duplicate the existing standard socket
mechanism for making a socket non-blocking.
 
Question 4: I see code that prevents read operations from blocking, but
nothing that prevents a write operation from blocking.  Is this an
oversight?
 
Somehow I get the feeling I'm missing something important here ...
 
Regards,
Al

[Tipc-discussion] What's status of test-suite

[<hek...@ya...>]

Sorry if I'm asking a stupid question.

I'm a little confused about the TIPC test source code
in CVS. There seem to be two directories:

1) tipc/test/tipc-benchmark/tipc
2) tipc/test/TIPC-test_suite

1) seems to contain the TIPC test C files included in the
project download area as "tipc_test ...." but those files
have been removed from CVS now and now the directory is
empty.

2) seems to a test suite different from the "tipc_test...tar.gz"
from the download area. And it has more complex header file 
dependancy on EnvAdaptation_SWI, TIPC_SWI, ....

I'm wondering what is the relationship among 1) and 2) and
the "tipc_test ....tar.gz" from the download section ? And
which one am I supposed to study as example TIPC applications?

Thanks
Kevin


--- "Jon Maloy (QB/EMC)" <jon...@er...> wrote:
> Hi Kevin,
> The procedure is very simple: convince me that you you are
> worthy, and I will add you as a developer at TIPC at SF. Then
> you can check in your patches yourself. I would prefer to review
> your patches first, though, especially in the beginning.
> 
> With your Makefile-patch I have a particular problem: I am
> in Europe right now, and can only read Ericsson emails via 
> a special Ericsson Web Mail Access system, which does not
> allow me to send or receive attachments. Please
> resend the mail with the patch to jon...@vi...,
> and send a cc to that address the next to weeks when you send
> me something. Since this is about a patch in a Makefile, I am
> certain that it will be ok. Are you also interested in being
> registered as a developer at SF ?
> 
> Regards /Jon
> 
> 
> -----Original Message-----
> From: hek...@ya...
> To: Jon Maloy (QB/EMC); tipc
> Sent: 01.04.2004 20:16
> Subject: Re: [Fwd: Re: [Tipc-discussion] tipc-1.3.08 and tipc_test-1.4 at SF]
> 
> 
> --- Jon Maloy <jon...@er...> wrote:
> >
> > I think most urgent now is to port the test suite developed by Nicolas
> > Gendron
> > et al (it is at SF) over to the new API, and ensure that it works all
> > the
> > way. 
> 
> I'm currently looking at code on CVS: test/TIPC-test_suite. So I'll 
> try to make it work with tipc-1.3.08
> 
> BTW what's the procedure to review/contribute TIPC patch to CVS ?
> 
> Thanks
> 
> Kevin
> 
> 

Re: [Tipc-discussion] Any Plans for Adding TIPC Support to "Ethereal"?

[Mark H. <ma...@os...>]

On Fri, 2004-04-02 at 07:41, all...@wi... wrote:
> Hi there:
>  
> Has any work been done by anyone towards adding support for TIPC to
> the Ethereal packet analyzer tool?  (See http://www.ethereal.com/ if
> you're unfamiliar with Ethereal.)
>  
> Do people think that this would be a good idea?  Does anyone have
> plans to do this work?  Just curious ...
>  
> Regards,
> Al Stephens

I have enclosed the ethereal add on for the current tipc protocol.  Jon
sent this out some time ago.  Jon said that an update for the new tipc
protocol has not been written yet.

Mark.


-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] Any Plans for Adding TIPC Support to "Ethereal"?

[<all...@wi...>]

Hi there:
 
Has any work been done by anyone towards adding support for TIPC to the
Ethereal packet analyzer tool?  (See http://www.ethereal.com/
<http://www.ethereal.com/>  if you're unfamiliar with Ethereal.)
 
Do people think that this would be a good idea?  Does anyone have plans to
do this work?  Just curious ...
 
Regards,
Al Stephens

RE: [Fwd: Re: [Tipc-discussion] tipc-1.3.08 and tipc_test-1.4 at SF]

[Jon M. (QB/EMC) <jon...@er...>]

Hi Kevin,
The procedure is very simple: convince me that you you are
worthy, and I will add you as a developer at TIPC at SF. Then
you can check in your patches yourself. I would prefer to review
your patches first, though, especially in the beginning.

With your Makefile-patch I have a particular problem: I am
in Europe right now, and can only read Ericsson emails via 
a special Ericsson Web Mail Access system, which does not
allow me to send or receive attachments. Please
resend the mail with the patch to jon...@vi...,
and send a cc to that address the next to weeks when you send
me something. Since this is about a patch in a Makefile, I am
certain that it will be ok. Are you also interested in being
registered as a developer at SF ?

Regards /Jon


-----Original Message-----
From: hek...@ya...
To: Jon Maloy (QB/EMC); tipc
Sent: 01.04.2004 20:16
Subject: Re: [Fwd: Re: [Tipc-discussion] tipc-1.3.08 and tipc_test-1.4 at SF]


--- Jon Maloy <jon...@er...> wrote:
>
> I think most urgent now is to port the test suite developed by Nicolas
> Gendron
> et al (it is at SF) over to the new API, and ensure that it works all
> the
> way. 

I'm currently looking at code on CVS: test/TIPC-test_suite. So I'll 
try to make it work with tipc-1.3.08

BTW what's the procedure to review/contribute TIPC patch to CVS ?

Thanks

Kevin

Re: [Fwd: Re: [Tipc-discussion] tipc-1.3.08 and tipc_test-1.4 at SF]

[<hek...@ya...>]

--- Jon Maloy <jon...@er...> wrote:
>
> I think most urgent now is to port the test suite developed by Nicolas
> Gendron
> et al (it is at SF) over to the new API, and ensure that it works all
> the
> way. 

I'm currently looking at code on CVS: test/TIPC-test_suite. So I'll 
try to make it work with tipc-1.3.08

BTW what's the procedure to review/contribute TIPC patch to CVS ?

Thanks

Kevin

[Tipc-discussion] Cross-compiling TIPC for UML and MIPs (Resend with patch)

[<hek...@ya...>]

Sorry, forgot to include patch in the last email.

[Tipc-discussion] Cross-compiling TIPC for UML and MIPs

[<hek...@ya...>]

Hello,

It seems TIPC-1.3.08 can only be compiled for i386 architecture.

The attached patch to linux 2.4's Makefile will make TIPC compilable for
linux 2.4.x on architectures including UML (user-mode-linux) and MIPs.

After applying the attached patch I tried compiling TIPC for 
UML 2.4.22 kernel and MIPs 2.4.18 kernel as the following. 
Both build OK (compilation for i386 is the same as before)

1. UML:
cd source/unstable/net/tipc/linux-2.4
make ARCH=um KINCLUDE=/home/hek/src/solos/src/kernel/uml-2.4.22/include

2. MIPs:
cd source/unstable/net/tipc/linux-2.4
make ARCH=mips KINCLUDE=~/src/kernel/linux-2.4.18-toshiba/include

How does this look like ?

Thanks

Kevin


--- Jon Maloy <jon...@er...> wrote:
>   I sent this mail to cgl_specs and cgl_discussion.
> For those of you who are not at these lists...
> 
> Cheers /jon
> 
> Hi all,
> As there has been some questions about the status of TIPC recently,
> I will give a brief summary here.
> 
> Large parts of the code has been rewritten over the last months, both
> to accommodate the Linux kernel community with regards to code style
> and more, but also to simplify and make it more maintainable in general.
> 
> The major changes are the following:
> 
> 1: Code and directory structure. I now looks much more like what you would
>     expect from linux kernel code. The need for continuous support for 
> 2.4, and
>    realizing that the directory structure at SF does not have to be the 
> same as the
>    the one we use for the code to the kernel tree, made me add a couple of
>    subdirectories, however. We will probably need a script to select the 
> correct files
>    for each targeted kernel tree.
> 
> 2: Basic things such as memory management, lock handling and
>     debug support has been completely rewritten. We now rely entirely on
>     the linux native memory management. We also have a much finer lock
>     granularity than previously, and the debug support has been greatly
>     simplified, still without loosing the good parts of it.
> 
> 3: The total source code volume (14000 lines) and module size (132 kbyte 
> stripped)
>     has been reduced, and there is potential for more.
> 
> 4: The API has been rewritten, and is now as conformant to POSIX as I 
> think it can
>      be. We support SOCK_STREAM, SOCK_SEQ_ACKET, SOCK_RDM,
>     SOCK_DGRAM, and connections can be established in two different, 
> compatible
>     ways: a TCP-style setup scheme and the traditional "non-protocol 
> message" TIPC
>     style. There is also a kernel-internal transport API, availabe for 
> drivers, upon which
>     the socket API is implemented.
> 
> 5: We have modified the protocol header and added the framwork for providing
>     reliable multicast, among other things. We have also added an 
> "unreliable transfer
>     mode" which can be set per socket. This makes it possible tho throw 
> way e.g. tunneled
>     IP-messages during overload (e.g. during DOS-attacks). The 
> functionality for reliable
>     multicast is not complete yet, though. A low-cost socket-to-socket 
> flow control support
>     has also been added.
> 
> 6: We are also working on an (optional) distributed management 
> functionality,
>     making it possible to interrogate and change configuration setting 
> in TIPC via
>     the /proc file system on on one of the cluster nodes.
> 
> Despite all these changes I have taken great care to maintain a high 
> degree of
> code portability, albeit very much on Linux' conditions. Structures and 
> function
> names (spin_lock_bh, sk_buff etc) used are the Linux ones, but they should
> be easily remappable to other OS-es by means of a few simple macros, not
> by changing a lot of  source code files.
> 
> The code is now back to a state where it is working basically on both 
> Linux 2.4 and
> Linux 2.6. But some parts, such as the management functionality and the 
> SOCK_STREAM
> interface have not been tested yet.  This will be done during April.
> 
> I have also spent some time on pushing TIPC within IETF.
> At IETF-59 in Seoul I presented the contents of an  Internet draft
> (http://www.ietf.org/internet-drafts/draft-maloy-tipc-00.txt) where The TIPC
> features, old and new ones, as well as the protocol are described.
> The presentation was received with great interest, but a lot remains to 
> be done
> before IETF will accept it as a standard.
> 
> Finally: I am planning to announce TIPC at the LKML within short.
> I would very much appreciate feedback about functionality, code, protocol
> and anything else that can contribute to make TIPC better.
> 
> Regards /Jon Maloy
> 
>  
> 
> This communication is confidential and intended solely for the addressee(s). Any unauthorized
> review, use, disclosure or distribution is prohibited. If you believe this message has been sent
> to you in error, please notify the sender by replying to this transmission and delete the
> message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, interruption, unauthorized
> amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are
> not liable for any such corruption, interception, amendment, tampering or viruses or any
> consequences thereof.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> TIPC-discussion mailing list
> TIP...@li...
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion

[Tipc-discussion] error in port.c

[Mark H. <ma...@os...>]

While doing some testing I ran across this.  Probably a cut/paste
error.  If there no objections I'll check in this change:

--- port.c	2004-03-26 15:52:20.000000000 -0800
+++ /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/port.c	2004-03-30 14:55:23.946174911 -0800
@@ -725,7 +725,7 @@
 		uport = dport->user_port;
                 usr_handle = uport->usr_handle;
                 connected = dport->publ.connected;
-                published = dport->publ.connected;
+                published = dport->publ.published;
 
 		if (unlikely(msg_errcode(msg)))
                         goto err;

-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] [Fwd: TIPC status March 2004]

[Jon M. <jon...@er...>]

  I sent this mail to cgl_specs and cgl_discussion.
For those of you who are not at these lists...

Cheers /jon

Hi all,
As there has been some questions about the status of TIPC recently,
I will give a brief summary here.

Large parts of the code has been rewritten over the last months, both
to accommodate the Linux kernel community with regards to code style
and more, but also to simplify and make it more maintainable in general.

The major changes are the following:

1: Code and directory structure. I now looks much more like what you would
    expect from linux kernel code. The need for continuous support for 
2.4, and
   realizing that the directory structure at SF does not have to be the 
same as the
   the one we use for the code to the kernel tree, made me add a couple of
   subdirectories, however. We will probably need a script to select the 
correct files
   for each targeted kernel tree.

2: Basic things such as memory management, lock handling and
    debug support has been completely rewritten. We now rely entirely on
    the linux native memory management. We also have a much finer lock
    granularity than previously, and the debug support has been greatly
    simplified, still without loosing the good parts of it.

3: The total source code volume (14000 lines) and module size (132 kbyte 
stripped)
    has been reduced, and there is potential for more.

4: The API has been rewritten, and is now as conformant to POSIX as I 
think it can
     be. We support SOCK_STREAM, SOCK_SEQ_ACKET, SOCK_RDM,
    SOCK_DGRAM, and connections can be established in two different, 
compatible
    ways: a TCP-style setup scheme and the traditional "non-protocol 
message" TIPC
    style. There is also a kernel-internal transport API, availabe for 
drivers, upon which
    the socket API is implemented.

5: We have modified the protocol header and added the framwork for providing
    reliable multicast, among other things. We have also added an 
"unreliable transfer
    mode" which can be set per socket. This makes it possible tho throw 
way e.g. tunneled
    IP-messages during overload (e.g. during DOS-attacks). The 
functionality for reliable
    multicast is not complete yet, though. A low-cost socket-to-socket 
flow control support
    has also been added.

6: We are also working on an (optional) distributed management 
functionality,
    making it possible to interrogate and change configuration setting 
in TIPC via
    the /proc file system on on one of the cluster nodes.

Despite all these changes I have taken great care to maintain a high 
degree of
code portability, albeit very much on Linux' conditions. Structures and 
function
names (spin_lock_bh, sk_buff etc) used are the Linux ones, but they should
be easily remappable to other OS-es by means of a few simple macros, not
by changing a lot of  source code files.

The code is now back to a state where it is working basically on both 
Linux 2.4 and
Linux 2.6. But some parts, such as the management functionality and the 
SOCK_STREAM
interface have not been tested yet.  This will be done during April.

I have also spent some time on pushing TIPC within IETF.
At IETF-59 in Seoul I presented the contents of an  Internet draft
(http://www.ietf.org/internet-drafts/draft-maloy-tipc-00.txt) where The TIPC
features, old and new ones, as well as the protocol are described.
The presentation was received with great interest, but a lot remains to 
be done
before IETF will accept it as a standard.

Finally: I am planning to announce TIPC at the LKML within short.
I would very much appreciate feedback about functionality, code, protocol
and anything else that can contribute to make TIPC better.

Regards /Jon Maloy

 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

[Fwd: Re: [Tipc-discussion] tipc-1.3.08 and tipc_test-1.4 at SF]

[Jon M. <jon...@er...>]

Hi,
The API changes are not binary compatible. (And not source code
compatible either, for that sake.) I think we can take that penalty now,
since the old version only is used by Ericsson people, and they are
maintaining
their own line for some time, at least. The ethereal module also needs
to be
updated, but I would wait with that, the IETF discussions and "reliable
multicast" implementation may still lead to further (small) changes in
the 
protocol header.

I think most urgent now is to port the test suite developed by Nicolas
Gendron
et al (it is at SF) over to the new API, and ensure that it works all
the
way. SOCK_STREAM and link changeover has not been tested, either. The
first
one is new, and the second one is partially rewritten, because I wanted
to simplify
 it. (We only support two active links per node pair now, instead of 4.)

Also, Kconfig is just a sketch now, and needs to be updated, smething
similar
to what you had in yours and Mika's version, but maintaining
possiblility to
standalone build. This requires default values when Kconfig is not used,
as far as I can understand. E.g. something like this (net.h):
#ifndef MAX_ZONES
#define MAX_ZONES 15
#endif

If you feel you have time for any of this, I would be very grateful.

Regards /Jon


Mark Haverkamp wrote:


On Mon, 2004-03-29 at 20:31, Jon Maloy wrote:

  

Hi all,

I just checked in a new version of the "unstable" TIPC, and added a
matching

file release. It is a lot more stable than the previous version, but it 

is not

ready to move over to the "stable" CVS package yet.

By mistake I put the file release under the "tipc_source" line, but when

considering it, I  don't think that is so bad to start using that one 

now, so

I will  let it stay there.



I also added a file release version of "tipc_test", the benchmark
program

I have been using as basic test program. It runs all the way to the end
at

my SMP machines, with a 2.6.4 kernel. It is infested with debug
printouts,

but should otherwise be useful for your testing.



Note that I have changed the directory structure and makefiles, to be

able to support both linux 2.4 and 2.6, as long as that is needed.

I realized that the SF directory structure under any circumstances

will be different from what TIPC will look like in the Linux kernel,

if/when that happens, so it does not really matter what we

put up there. It should just be as maintainable as possible for
ourselves.



I will be in Europe the next two weeks, and will not be able to do much

programming over there. But I will read and answer emails.



Regards /Jon

    



I have the new driver running on my 2.6.5-rc2 SMP machines.  I initially

had problems using applications though.  Even though the tipc drivers

could see each other I couldn't communicate between applications.  I did

some looking around and found the the format of sockaddr_tipc changed. 

There is a scope element.  This breaks any already compiled code running

on the previous versions of tipc.



Also, has anyone updated the ethereal tipc module to work with the new

protocol version?





Mark.

  


 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Re: [Tipc-discussion] tipc-1.3.08 and tipc_test-1.4 at SF

[Mark H. <ma...@os...>]

On Mon, 2004-03-29 at 20:31, Jon Maloy wrote:
> Hi all,
> I just checked in a new version of the "unstable" TIPC, and added a matching
> file release. It is a lot more stable than the previous version, but it 
> is not
> ready to move over to the "stable" CVS package yet.
> By mistake I put the file release under the "tipc_source" line, but when
> considering it, I  don't think that is so bad to start using that one 
> now, so
> I will  let it stay there.
> 
> I also added a file release version of "tipc_test", the benchmark program
> I have been using as basic test program. It runs all the way to the end at
> my SMP machines, with a 2.6.4 kernel. It is infested with debug printouts,
> but should otherwise be useful for your testing.
> 
> Note that I have changed the directory structure and makefiles, to be
> able to support both linux 2.4 and 2.6, as long as that is needed.
> I realized that the SF directory structure under any circumstances
> will be different from what TIPC will look like in the Linux kernel,
> if/when that happens, so it does not really matter what we
> put up there. It should just be as maintainable as possible for ourselves.
> 
> I will be in Europe the next two weeks, and will not be able to do much
> programming over there. But I will read and answer emails.
> 
> Regards /Jon

I have the new driver running on my 2.6.5-rc2 SMP machines.  I initially
had problems using applications though.  Even though the tipc drivers
could see each other I couldn't communicate between applications.  I did
some looking around and found the the format of sockaddr_tipc changed. 
There is a scope element.  This breaks any already compiled code running
on the previous versions of tipc.

Also, has anyone updated the ethereal tipc module to work with the new
protocol version?


Mark.
-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] tipc-1.3.08 and tipc_test-1.4 at SF

[Jon M. <jon...@er...>]

Hi all,
I just checked in a new version of the "unstable" TIPC, and added a matching
file release. It is a lot more stable than the previous version, but it 
is not
ready to move over to the "stable" CVS package yet.
By mistake I put the file release under the "tipc_source" line, but when
considering it, I  don't think that is so bad to start using that one 
now, so
I will  let it stay there.

I also added a file release version of "tipc_test", the benchmark program
I have been using as basic test program. It runs all the way to the end at
my SMP machines, with a 2.6.4 kernel. It is infested with debug printouts,
but should otherwise be useful for your testing.

Note that I have changed the directory structure and makefiles, to be
able to support both linux 2.4 and 2.6, as long as that is needed.
I realized that the SF directory structure under any circumstances
will be different from what TIPC will look like in the Linux kernel,
if/when that happens, so it does not really matter what we
put up there. It should just be as maintainable as possible for ourselves.

I will be in Europe the next two weeks, and will not be able to do much
programming over there. But I will read and answer emails.

Regards /Jon

 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

[Tipc-discussion] Could you take a look at this

[Mark H. <ma...@os...>]

I got around to cleaning up all the compile errors with the 2.6 kernel. 
I have enclosed diffs.  If these seem correct, I can check them in.

Thanks,
Mark.
---------


diff -Nru --exclude=CVS /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/port.c /home/markh/views/tipc/cvs/source/unstable/net/tipc/port.c
--- /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/port.c	2004-03-11 07:33:30.000000000 -0800
+++ /home/markh/views/tipc/cvs/source/unstable/net/tipc/port.c	2004-03-26 11:34:48.170290279 -0800
@@ -467,7 +467,7 @@
                 this = port_lock_deref(msg_destport(msg));
                 if (this->publ.connected)
                         port_abort_self(this,err);
-                spin_unlock_bh(this->lock);
+                spin_unlock_bh(this->publ.lock);
         }
 	tipc_reject_msg(buf,err);
 }
@@ -621,7 +621,7 @@
         this->probing_state = CONFIRMED;
         port_incr_out_seqno(this);
  exit:
-        spin_unlock_bh(this->lock);
+        spin_unlock_bh(this->publ.lock);
         buf_discard(buf);
 }
 #define DBG_OUTPUT 0
@@ -732,7 +732,7 @@
                         tipc_conn_msg_event cb = uport->conn_msg_cb;
                         tipc_ref_t peer_port = port_peerport(dport);
                         tipc_net_addr_t peer_node = port_peernode(dport);
-                        spin_unlock_bh(dport->lock);
+                        spin_unlock_bh(dport->publ.lock);
                         if (unlikely(!connected)) {
                                 if (unlikely(published))
                                         goto reject;
@@ -750,7 +750,7 @@
                 }
                 case TIPC_DIRECT_MSG:{
                         tipc_msg_event cb = uport->msg_cb;
-                        spin_unlock_bh(dport->lock);
+                        spin_unlock_bh(dport->publ.lock);
                         if (unlikely(connected))
                                 goto reject;
                         if (unlikely(!cb))
@@ -761,7 +761,7 @@
                 }
                 case TIPC_NAMED_MSG:{
                         tipc_named_msg_event cb = uport->named_msg_cb;
-                        spin_unlock_bh(dport->lock);
+                        spin_unlock_bh(dport->publ.lock);
                         if (unlikely(connected))
                                 goto reject;
                         if (unlikely(!cb))
@@ -787,7 +787,7 @@
                         tipc_conn_shutdown_event cb = uport->conn_err_cb;
                         tipc_ref_t peer_port = port_peerport(dport);
                         tipc_net_addr_t peer_node = port_peernode(dport);
-                        spin_unlock_bh(dport->lock);
+                        spin_unlock_bh(dport->publ.lock);
                         if (!connected || !cb)
                                 break;
                         if (msg_origport(msg) != peer_port)
@@ -801,7 +801,7 @@
                 }
                 case TIPC_DIRECT_MSG:{
                         tipc_msg_err_event cb = uport->err_cb;
-                        spin_unlock_bh(dport->lock);
+                        spin_unlock_bh(dport->publ.lock);
                         if (connected || !cb)
                                 break;
                         cb(usr_handle,dref,msg_data(msg),msg_data_sz(msg), 
@@ -810,7 +810,7 @@
                 }
                 case TIPC_NAMED_MSG:{
                         tipc_named_msg_err_event cb = uport->named_err_cb;
-                        spin_unlock_bh(dport->lock);
+                        spin_unlock_bh(dport->publ.lock);
                         if (connected || !cb)
                                 break;
                         dseq.type =  msg_nametype(msg);
@@ -856,7 +856,7 @@
                 k_signal((Handler)port_dispatcher_sigh, 0);
         }
         spin_unlock_bh(&queue_lock);
-        spin_unlock_bh(port->lock);
+        spin_unlock_bh(this->lock);
 	return TIPC_OK;
 }
 
@@ -869,7 +869,7 @@
 {
 	struct user_port *this = ((struct port*)port)->user_port;
 	tipc_continue_event cb;
-        spin_unlock_bh(port->publ.lock);
+        spin_unlock_bh(port->lock);
 	cb = this->continue_event_cb;
 	if (cb)
 		cb(this->usr_handle,port->ref);
diff -Nru --exclude=CVS /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/proc.c /home/markh/views/tipc/cvs/source/unstable/net/tipc/proc.c
--- /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/proc.c	2004-03-09 09:29:32.000000000 -0800
+++ /home/markh/views/tipc/cvs/source/unstable/net/tipc/proc.c	2004-03-26 11:44:16.675530840 -0800
@@ -51,7 +51,6 @@
 #include <linux/poll.h>
 #include <linux/dirent.h>
 #include <linux/list.h>
-#include <stdio.h>
 
 #include <tipc_adapt.h>
 #include <tipc_msg.h>
diff -Nru --exclude=CVS /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/socket.c /home/markh/views/tipc/cvs/source/unstable/net/tipc/socket.c
--- /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/socket.c	2004-03-11 07:33:30.000000000 -0800
+++ /home/markh/views/tipc/cvs/source/unstable/net/tipc/socket.c	2004-03-26 11:26:52.240799868 -0800
@@ -429,7 +429,7 @@
 #else
 static int
 send_msg(struct kiocb *iocb, struct socket *sock,
-	struct msghdr *m, int total_len)
+	struct msghdr *m, size_t total_len)
 #endif
 {
 	int res = -EINVAL;
@@ -489,7 +489,7 @@
 #else
 static int
 send_packet(struct kiocb *iocb, struct socket *sock,
-	struct msghdr *m, int total_len)
+	struct msghdr *m, size_t total_len)
 #endif
 {
 	int res;
@@ -497,7 +497,11 @@
         struct sockaddr_tipc *dest = (struct sockaddr_tipc *) m->msg_name;
 
 	if (unlikely(dest))
+#ifdef TIPC_LINUX_2_4
 		return send_msg(sock,m,total_len,scm);
+#else
+		return send_msg(0, sock, m, total_len);
+#endif
 
 	if (down_interruptible(&tsock->sem))
 		return -ERESTARTSYS;
@@ -540,7 +544,7 @@
 #else
 static int
 send_stream(struct kiocb *iocb, struct socket *sock,
-		struct msghdr *m, int total_len)
+		struct msghdr *m, size_t total_len)
 #endif
 {
 	uint i,o,sz;
@@ -549,7 +553,11 @@
 	struct msghdr msg;
 	unchar *crs;
 	uint rest;
+#ifdef TIPC_LINUX_2_4
 	int res = send_packet(sock,m,0,0);
+#else
+	int res = send_packet(0, sock, m, 0);
+#endif
 
 	if (likely(res != -EINVAL))
 		return res;
@@ -588,7 +596,11 @@
 			crs+= ov[o].iov_len;
 			rest-= ov[o].iov_len;
 		}
+#ifdef TIPC_LINUX_2_4
 		res = send_packet(sock,&msg,0,0);
+#else
+		res = send_packet(0, sock, &msg, 0);
+#endif
 		sz = o = 0;
 	}
 	return res;
@@ -642,7 +654,7 @@
 #else
 static int
 recv_msg(struct kiocb *iocb, struct socket *sock,
-	struct msghdr *m, int buf_len, int flags)
+	struct msghdr *m, size_t buf_len, int flags)
 #endif
 {
 	struct iovec *iv = m->msg_iov;
@@ -721,7 +733,7 @@
 #else
 static int
 recv_stream(struct kiocb *iocb, struct socket *sock,
-	    struct msghdr *m, int buf_len, int flags)
+	    struct msghdr *m, size_t buf_len, int flags)
 #endif
 {
 	struct tipc_sock *tsock = get_tipc_sock(sock);
@@ -900,7 +912,11 @@
 
    /* Send a 'SYN', i.e. an empty connectionless msg to dest: */
    m.msg_name = dst;
+#ifdef TIPC_LINUX_2_4
    send_msg(sk,&m,0,0);
+#else
+   send_msg(0, sk, &m, 0);
+#endif
 
    if (down_interruptible(&tsock->sem)) 
            return -ERESTARTSYS;
@@ -962,7 +978,11 @@
                 if (!msg_data_sz(buf_msg(tsock->queue_head))){
                         struct msghdr m = {0,};
                         dbg("accept %x, sending SYN\n",sk);
+#ifdef TIPC_LINUX_2_4
                         send_packet(newsk,&m,0,0);      
+#else
+                        send_packet(0, newsk, &m, 0);      
+#endif
                         advance_queue(tsock);
                         goto exit;
                 }
@@ -1237,7 +1257,7 @@
 		s->usr_handle = (void *) tsock->p->ref;
 		s->usr_next = tsock->sub_list;
 		tsock->sub_list = s;
-                spin_unlock_bh(&tsock->p->lock);
+                spin_unlock_bh(tsock->p->lock);
 		put_user(s->s.ref, &((struct tipc_subscr *) arg)->ref);
 		up(&tsock->sem);
 		return 0;
diff -Nru --exclude=CVS /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/udp_media.c /home/markh/views/tipc/cvs/source/unstable/net/tipc/udp_media.c
--- /home/markh/views/tipc/cvs_rw/source/unstable/net/tipc/udp_media.c	2004-02-16 15:00:02.000000000 -0800
+++ /home/markh/views/tipc/cvs/source/unstable/net/tipc/udp_media.c	2004-03-26 11:52:20.918351469 -0800
@@ -140,7 +140,11 @@
 	bearer.iov.iov_len = length;
         msg_dbg(buf_msg(skb),"Sending:");
 	bearer.udp_hdr.msg_name = (void *)&dest->dev_addr.addr_in;
+#ifdef TIPC_LINUX_2_4
         if (atomic_read(&sk->sk->wmem_alloc) < sk->sk->sndbuf){
+#else
+        if (atomic_read(&sk->sk->sk_wmem_alloc) < sk->sk->sk_sndbuf){
+#endif
                  sock_sendmsg(sk, &bearer.udp_hdr, length);
         }
 	set_fs(saved_addr);

-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] [PATH] tipc RM local host communication stablization

[Guo, M. <mi...@in...>]

 Hi,Jon

	Xiaofeng and I debug the RM on local host and the following is
the stabilization patch for local host communication!
For inter node communication, we are still on debugging, and I find that
packets can not be transmitted among the different nodes on the=20
links, any updates on the link transmission?

Thanks
Guo min

--------------------
Index: bcast.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/develop/tipc2/net/tipc/bcast.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.4.2
diff -u -r1.1.1.2 -r1.1.1.2.4.2
--- bcast.c	18 Mar 2004 07:28:32 -0000	1.1.1.2
+++ bcast.c	19 Mar 2004 06:13:15 -0000	1.1.1.2.4.2
@@ -430,9 +436,10 @@
 	int size =3D sizeof (struct mc_identity);
=20
 	mc_list =3D (struct mc_identity*)k_malloc(size);
-	if (mc_list =3D=3D NULL)
+	if (mc_list =3D=3D NULL){
+		dbg("mc_indentity_create malloc error");=09
 		return false;
-=09
+	}
 	mc_list->port =3D destport;
 	mc_list->node =3D destnode;=09
 	list_add_tail(&mc_list->list,list_head);
@@ -492,15 +499,14 @@
 void free_mclist(struct list_head *list_head)
 {
 	struct mc_identity* mid;
-	struct list_head *pos;=09
+	struct list_head *tmp;=09
 =09
-	list_for_each(pos,list_head) {
-		mid =3D list_entry(pos, struct mc_identity, list);
-		list_del(&mid->list);
-		kfree(mid);
-	=09
+	while(!list_empty(list_head)) {
+		tmp =3D list_head->next;
+		list_del(tmp);
+		kfree(list_entry(tmp, struct mc_identity, list));
 	}
-	list_del(list_head);
+
 }
=20
 static struct list_head point =3D LIST_HEAD_INIT(point);
=20
Index: name_table.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/develop/tipc2/net/tipc/name_table.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.4.3
diff -u -r1.1.1.2 -r1.1.1.2.4.3
--- name_table.c	18 Mar 2004 07:28:32 -0000	1.1.1.2
+++ name_table.c	19 Mar 2004 06:13:15 -0000	1.1.1.2.4.3
@@ -729,21 +738,20 @@
    		spin_unlock_bh(&seq->lock);
    		goto not_found;
    	=09
-   	}
-   	=09
+   	}  	=09
    	do {
 	   	destnode =3D publ->node;=20
 	   	destport =3D publ->ref;
- 		if ( false =3D=3D
mc_indenity_create(mc_head,destport,destnode))
-			goto found;   		   =09
+   	 	if (destport)
+   		{
+			if ( false =3D=3D
mc_indenity_create(mc_head,destport,destnode)){
+				 spin_unlock_bh(&seq->lock);

+				goto not_found;   =09
+			}=09
+		}  =20
 		publ=3D publ->cluster_list.next;
    	}while(publ !=3D seq->sseqs[i].cluster_list);
-   =09
-   	if (destport)
-   	{
-		if ( false =3D=3D
mc_indenity_create(mc_head,destport,destnode))
-				goto found;   =09
-	}	=09
+   		=09
    }=09
   if (list_empty(mc_head))
   {
@@ -775,12 +783,11 @@
    tipc_net_addr_t destnode;
=20
    read_lock_bh(&nametbl_lock);=20
+
    seq =3D nametbl_find_seq(type);=20
    if (!seq) goto not_found;  =20
-
    sseq =3D nameseq_available(seq,lower,upper);  =20
    if (!sseq) goto not_found;  =20
-  =20
    low_seq =3D nameseq_find_insert_pos(seq,lower);   =20
    if (low_seq < 0)
    	low_seq =3D low_seq < 0 ? ~low_seq : low_seq;
@@ -791,11 +798,11 @@
 	 =20
    if (high_seq < low_seq)
    	 goto not_found;=20
-  =20
-   spin_lock_bh(&seq->lock);
=20
-   i =3D low_seq;
-  =20
+  spin_lock_bh(&seq->lock);
+
+  i =3D low_seq;
+
   for (i =3D low_seq ; i <=3D high_seq; i++)
    {
    	publ =3D seq->sseqs[i].node_list;
@@ -813,9 +820,11 @@
 		}
 	}	=09
    }=09
-  if (list_empty(mc_head))
+
+  if (list_empty(mc_head)) {
   	spin_unlock_bh(&seq->lock);
   	goto not_found;
+  }
    	spin_unlock_bh(&seq->lock);
    	read_unlock_bh(&nametbl_lock);=20
    	return true;
Index: recvbcast.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/develop/tipc2/net/tipc/recvbcast.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.4.1
diff -u -r1.1.1.2 -r1.1.1.2.4.1
--- recvbcast.c	18 Mar 2004 07:28:32 -0000	1.1.1.2
+++ recvbcast.c	19 Mar 2004 05:01:29 -0000	1.1.1.2.4.1
@@ -327,7 +330,7 @@
 		struct list_head *pos;
 		struct mc_identity *mid;
 		int res;
-	=09
+		printk("nameseq_deliver\n");

 		list_for_each(pos,mc_head) {
 			mid =3D list_entry(pos, struct mc_identity, list);

 			if(mid && mid ->node =3D=3D tipc_own_addr) {
@@ -435,18 +438,22 @@
 int bcast_port_recv(struct sk_buff *buf)
 {
 	struct list_head mc_head;
+	struct tipc_msg *msg;
 	int res;
 =09
 	INIT_LIST_HEAD(&mc_head);
-	struct tipc_msg *msg =3D buf_msg(buf);
+	msg =3D buf_msg(buf);
+	res =3D true;
 =09
 	if (false =3D=3D nametbl_self_translate(&mc_head,msg_nametype(msg),\
 			msg_namelower(msg),msg_nameupper(msg))) {
 			buf_discard(buf);
+			printk("get TIPC_ERR_NO_PORT\n");

 			return TIPC_ERR_NO_PORT;
 	}
 	res =3D nameseq_deliver(buf,&mc_head);
 	free_mclist(&mc_head);
+ok:=09
 	return res;
 }
=20
Index: sendbcast.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/cvs/develop/tipc2/net/tipc/sendbcast.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.4.3
diff -u -r1.1.1.2 -r1.1.1.2.4.3
--- sendbcast.c	18 Mar 2004 07:28:32 -0000	1.1.1.2
+++ sendbcast.c	19 Mar 2004 06:13:15 -0000	1.1.1.2.4.3
@@ -156,24 +165,32 @@
 	struct sk_buff *copybuf;
 	tipc_net_addr_t  prev_destnode;
=20
+
 	m =3D &this->publ.phdr;
 	if (importance <=3D 3)
 		msg_set_importance(m,importance);
-=09
+
+
 	list_for_each(pos,mc_head) {
 		prev_destnode =3D 0;
 		mid =3D list_entry(pos,struct mc_identity,list);=20
 		if (mid !=3D NULL && (prev_destnode !=3D mid->node)){
 			prev_destnode =3D mid->node;
-			copybuf =3D buf_acquire(msg_size(m));
-	       	memcpy(copybuf,buf,msg_size(m));
+			copybuf =3D buf_clone(buf);
 			msg_set_destnode(buf_msg(copybuf), mid ->node);
-			if (likely(mid ->node !=3D tipc_own_addr))
+			if (likely(mid ->node !=3D tipc_own_addr)) {
+				printk("ERRRRR\n");
 				res =3D
tipc_send_buf_fast(copybuf,mid->node);
-			else
+			}
+			else{
 				res =3D bcast_port_recv(copybuf);
+				if(res !=3D 0)
+					break;
+			}
 		}
 	}
+	ok:
+	buf_discard(buf);
 	return res;
 }
 /**
@@ -240,27 +257,29 @@
 	uint count,res;
 	struct tipc_msg* hdr;
 	struct tipc_portid orig;
-	struct port *this =3D (struct port*)ref_deref(ref);
-        struct sk_buff* b;
-=09
-        if (!this)=20
-                return TIPC_FAILURE;
+    struct sk_buff* b;
+  	struct port *this =3D (struct port*)ref_deref(ref);
+
+
+    if (!this)=20
+        return TIPC_FAILURE;
 	INIT_LIST_HEAD(&mc_head);=09
-	nametbl_mc_translate(&mc_head, seq->type,seq->lower,seq->upper);

+	res =3D nametbl_mc_translate(&mc_head,
seq->type,seq->lower,seq->upper);=20
+	if(res =3D=3D false)
+        return TIPC_ERR_NO_NAME;
 	tipc_ownidentity(ref,&orig);
-        hdr =3D &this->publ.phdr;
-=09
+	hdr =3D &this->publ.phdr;
 	msg_set_type(hdr,TIPC_MCAST_MSG);
-        msg_set_nametype(hdr,seq->type);
-        msg_set_namelower(hdr,seq->lower);
-        msg_set_nameupper(hdr,seq->upper);
+	msg_set_nametype(hdr,seq->type);
+	msg_set_namelower(hdr,seq->lower);
+	msg_set_nameupper(hdr,seq->upper);
 	msg_set_hdr_sz(hdr,MCAST_H_SIZE);
-        res =3D msg_build(hdr,msg,scnt,TIPC_MAX_MSG_SIZE,&b);
-        if (!b)
+	res =3D msg_build(hdr,msg,scnt,TIPC_MAX_MSG_SIZE,&b);
+	if (!b) {
+  		free_mclist(&mc_head);
                 return TIPC_FAILURE;
-=09
+        }=09
 	count =3D count_mc_member(&mc_head);=09
-=09
 	if (count <=3D REPLICA_NODES){
 		res =3D tipc_forward_buf2nameseq(ref,(struct
tipc_name_seq*)seq,
=20
b,&orig,res,17,&mc_head);
@@ -270,6 +289,7 @@
 		check_bcast_outqueue();
 		res =3D tipc_bsend_buf(b,&mc_head);
 	}=09
+	free_mclist(&mc_head);
 	return res;
 }
=20

Re: [Tipc-discussion] 64-bit processor node id

[Kevin K. He <he...@ya...>]

Hi Jon,

Thank you so much for all the detailed answers to 
all my questions! 

I am very interested in the idea of making node address
insignficant or updatable by applications (assuming 
application can gurantee the new node id is unique
in the cluster). This will enable a very dynamic
cluster configuration. But I understand it's not easy.

I'd be happy to be in the loop :)

Kevin

--- Jon Maloy <jon...@er...> wrote:

---------------------------------
  What will happen is that the two nodes will never connect
to each other, and the rest of the nodes in the cluster will be
very confused about this node, because there will be two
sources in the same plane, presenting themselves as this node,
but with different MAC addresses.
 I may be a good idea to do as you suggest, after all the intention
is that node addresses should not be significant or even used by
well-designed applications. But I have to giv this a little more
thought.

/jon

Kevin Kaichuan He wrote:
  
  It seems that we can't squeeze MAC address in the 12-bit node id. Then what will happen if two
processor use the same node id ? Will TIPC automatically detect the collision and even
automatically resolve  the collision by assigning unique node id to each other ? Does this sound a
bad idea to implement if it's not there yet ? Kevin  
      
--- "Ling, Xiaofeng" <xia...@in...> wrote:    
          
currently nodeid is only 12bit, and a whole tipc address is 32bit, including zone,cluster, andnode
three part.Seems it is not so simple to change it to 64bit.      
              
-----Original Message-----From: tip...@li...
[mailto:tip...@li...] On Behalf Of Kevin Kaichuan HeSent:
2004&Auml;&ecirc;3&Ocirc;&Acirc;12&Egrave;&Otilde; 12:57To:
tip...@li...Subject: [Tipc-discussion] 64-bit processor node idCurrently
I see the driver.c uses a "int node" to storethe process node id.  So it will be 32-bit node id
on32-bit processors.I am thinking that whether we can make it 64-bit. The reason is that 64-bit
integer is enough to store ethernet MAC address. So in order to generate a cluster-wide unique
node id the managment planes on different nodes don't need exchange any network packets because
they can simply use MAC addresses as their node ids.One motivation of using TIPC in our project is
that we can avoid the complexity of IP address managment in a stack of L2 switches. With 64-bit
node id, I guess every node in our stack can start tipc totally independent from others.Will there
be negative impact of 64-bit node id on the tipc ?Thank
you!Kevin-------------------------------------------------------This SF.Net email is sponsored by:
IBM Linux TutorialsFree Linux tutorial presented by Daniel Robbins, President and CEO of GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click_______________________________________________TIPC-discussion
mailing list
TIP...@li...https://lists.sourceforge.net/lists/listinfo/tipc-discussion 
      
              
    
    
-------------------------------------------------------This SF.Net email is sponsored by: IBM
Linux TutorialsFree Linux tutorial presented by Daniel Robbins, President and CEO ofGenToo
technologies. Learn everything from fundamentals to
systemadministration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click_______________________________________________TIPC-discussion
mailing
lis...@li...https://lists.sourceforge.net/lists/listinfo/tipc-discussion
 

 

This communication is confidential and intended solely for the addressee(s). Any unauthorized
review, use, disclosure or distribution is prohibited. If you believe this message has been sent
to you in error, please notify the sender by replying to this transmission and delete the message
without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized
amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are
not liable for any such corruption, interception, amendment, tampering or viruses or any
consequences thereof.