On Jan 20, 2011, at 2:57 AM, Michael Tuexen wrote: > On Jan 20, 2011, at 5:41 AM, Kacheong Poon wrote: >> On 01/20/11 06:27 AM, Schoch Christian wrote: >>> I could figure a problem with spinfo_state between Linux and FreeBSD >>> sctp stack. >>> >>> While in linux stack the return value of spinfo_state is defined as enum >>> with four items, FreeBSD defines a lot more states. The problem is that >>> these values do not match with each other. For example if FreeBSD means >>> INACTIVE this value in linux results in UNCONFIRMED. >>> >>> In sctp socket api these states are namely defined but not assoziated >>> with any value. >>> >>> Is there any possibility to standardize these values ?? >> >> >> In version 25 of the draft, there are 3 defined values for >> spinfo_state, which are >> >> SCTP_UNCONFIRMED: The initial state of a peer address. >> >> SCTP_ACTIVE: The state is entered the first time after path >> verification. It can also be entered if the state is >> SCTP_INACTIVE and the path supervision detects that the peer >> address is reachable again. >> >> SCTP_INACTIVE: This state is entered whenever a path failure is >> detected. >> >> The above values should be used. App should not use actual integer >> value in the code. > I agree with you here completely. > Please note that FreeBSD does not implement the path state handling > according to rev 25 of the ID yet. We only implement parts of ID 25 that we had already done... and we may do a bit more.. but I really don't expect a major rev to the API until we get through last call.. since thing do tend to change ;-) R >> >> What is your reason that actual integer values are needed? >> >> >> -- >> >> K. Poon. >> ka-cheong.poon@xxxxxxxxxx >> > ----- Randall Stewart randall@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
