From: Stephens, A. <all...@wi...> - 2007-12-20 17:39:51
|
Reposted to general TIPC mailing list for wider circulation.=20 -----Original Message----- From: Ren...@su... [mailto:Ren...@su...]=20 Sent: Wednesday, December 19, 2007 1:54 AM To: Lau...@su... 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. Lau...@Su... a =E9crit : >=20 >> PROPOSED AGENDA: >> >> - TIPC on Solaris progress report >=20 > Hi Al and Elmer, >=20 > I'm in vacation in a few minutes, but Renaud M=E9trich 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. >=20 > My objective was to have most of the code compiling on solaris, and=20 > try to get 'tipc-config -s' return something, before I went to=20 > vacation. And it returns something ! >=20 > $ tipc-config -s > invalid reply message received via TIPC >=20 > Not what I expected :-) > But part of it went well : > The tipc-config command opens a socket, calls setsockopt() and=20 > 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. >=20 > Then on the tipc-config side, sendto() returns, and tipc-config calls=20 > poll(). >=20 > The kernel is executing the task that was preciously scheduled by=20 > tipc_port_recv_msg(). > port_dispatcher_sigh() sees that it is a TIPC_NAMED_MSG and calls the=20 > callback cfg_named_msg_event() which calls tipc_show_stats() and send=20 > the reply by calling tipc_send_buf2port(). > Finally the callback dispatch() from our socket module is called, it=20 > will enqueue the message and do a poll wakeup. >=20 > 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=20 > and type have wrong values. >=20 > I still need to debug this. > The vxworks code was very helpfull for the sk_buff management. But=20 > there are some more pointers in mblk_t solaris structures that I=20 > surely didn't manage correctly somewhere. Or the problem may be in=20 > what I did to transfer the kernel data to the specific uio structure. >=20 > Apart from that, I've coded the tipc_eth_media but not tested. > And several socket callbacks aren't yet coded : accept, bind, listen,=20 > connect... > Still some work for January ! >=20 > Have a nice break > Bye >=20 >=20 -- Renaud |