Reposted to general TIPC mailing list for wider circulation. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 1:54 AM To: [EMAIL PROTECTED] Cc: Stephens, Allan; Horvath, Elmer Subject: Re: [tipc-discussion] REMINDER - TIPC Working Group Meeting on Thursday
Hello people, I am the backup of Laurent. I worked past few weeks on having the necessary glue implemented in the Solaris 10 kernel to be able to implement new socket types, in our case AF_TIPC. I thought I could attend the meeting tomorrow but forgot a critical appointment I had downtown this day. I'm sorry but I won't be able to attend. cheers, Renaud. [EMAIL PROTECTED] a écrit : > >> PROPOSED AGENDA: >> >> - TIPC on Solaris progress report > > Hi Al and Elmer, > > I'm in vacation in a few minutes, but Renaud Métrich will be able to > attend the meeting. > Renaud investigated how to implement the TIPC socket module on Solaris > 10, and knows what I did while porting on OpenSolaris. > > My objective was to have most of the code compiling on solaris, and > try to get 'tipc-config -s' return something, before I went to > vacation. And it returns something ! > > $ tipc-config -s > invalid reply message received via TIPC > > Not what I expected :-) > But part of it went well : > The tipc-config command opens a socket, calls setsockopt() and > sendto() to send a message TIPC_CMD_SHOW_STATS to the socket. > The message is received by our socket kernel module, > tipc_port_recv_msg() is called, calls port_dispatcher() that schedules > a task. > > Then on the tipc-config side, sendto() returns, and tipc-config calls > poll(). > > The kernel is executing the task that was preciously scheduled by > tipc_port_recv_msg(). > port_dispatcher_sigh() sees that it is a TIPC_NAMED_MSG and calls the > callback cfg_named_msg_event() which calls tipc_show_stats() and send > the reply by calling tipc_send_buf2port(). > Finally the callback dispatch() from our socket module is called, it > will enqueue the message and do a poll wakeup. > > tipc-config is awaken and calls recv(). The kernel module dequeues the > message, transfers it to a specific user io structure. > tipc-config receives it in an answer , but header contents like len > and type have wrong values. > > I still need to debug this. > The vxworks code was very helpfull for the sk_buff management. But > there are some more pointers in mblk_t solaris structures that I > surely didn't manage correctly somewhere. Or the problem may be in > what I did to transfer the kernel data to the specific uio structure. > > Apart from that, I've coded the tipc_eth_media but not tested. > And several socket callbacks aren't yet coded : accept, bind, listen, > connect... > Still some work for January ! > > Have a nice break > Bye > > -- Renaud ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
