[tipc-discussion] Update on Solaris port for TIPC (follow up)

[Stephens, A. <all...@wi...>]

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