On 11/11/08 02:13 PM, Rao Shoaib wrote: >>> >>> *) To support evolution the interface is versioned. >>> Current versions are obtained via the macros >>> SOCK_UC_VERSION (upcall interface) >>> SOCK_DC_VERSION (downcall interface) >>> >> >> How do you expect these to be used? > As the document says we are only providing hooks, we have not > implemented the code to deal with backward compatibility. So this is > how we envision it to work. When the socket module is loaded it > registers with the socket framework, the create function, these two > versions and an over all version number. These versions uniquely > identify the up and downcalls on the system where the module was > compiled (assuming that is what the module can support). The socket > frame work can than verify if it supports these versions and if so > those versions/implementation is used with the socket else the > registration is failed. The over all version number will only be > changed in the event of a major change that makes it impossible to > support legacy modules.
The only lingering question I have is whether or not the version is better where you've put it or in the structures for up/down calls themselves. In the new pdf, there appear to be other changes, such as those to su_newconn. Are those changes related to this case (and not mentioned) or are they relevant to some other feedback, in which case, can I ask for a PDF that is marked up with just changes related to this case? I suppose what I'm wondering is whether the list of changes in the email for the case was complete or whether we should consider that to be just the highlights and read the PDF for full discovery? Darren
