On 10/29/08 03:47, [EMAIL PROTECTED] wrote:
On (10/29/08 12:02), Kacheong Poon wrote:
Space may not be an issue here. But if you are talking about
using it generally, I guess it can be an issue in other cases.
What convenience routines are you referring to? For example,
do you mean a routine to compare two socket addresses? Then
I guess that the routine will need to be do comparison on all
the necessary fields. But if a caller just uses sockaddr_storage
to store an IP address and wants to use the aforementioned
compare routine, then I guess it will need to do some unnecessary
initialization to make it work. Or is there a special family type
to indicate IP address only in a sockaddr_storage?
The drawback of sockaddr_storage are that it has space for
things like sin_port in it, which may not be useful in all cases.
But most system call data (e.g., lifreq) are using sockaddr_storage,
so they are handy to pass around.
If we choose to have a general address storage structure, we
should make it shareable across all the libraries, instead of
reinventing this with each library.
FWIW, in net_inject() where a consumer is required to supply address
information, sockaddr_storage is provided as the container for that
address.
In other parts of the pfhooks APIs, a "struct sockaddr *" is used/provided
under the assumption that the consumer is supplying a correctly sized
object for what is expected to be stored (net_getlifaddr) or the value
of sin_family provides that information (net_routeto).
The use of sockaddr_storage also benefits from it being available
on other platforms. Thus if we standardise on it then others need
to do less work to benefit from further work we do in this area.
As a side note, sockaddr_storage is also large enough to contain
a complete sockaddr_un, so code that uses sockaddr_storage for
working with AF_INET/AF_INET6 is also likely to be safer if
it is changed to work with AF_UNIX, etc.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
