Darren Reed ??:
> The subject really sums up what this email is about...
>
> The the various network layer protocols that are common,
> we have AF_* names and for the ones that we support in
> the code base, we have "struct sockaddr_*" - e.g.
> AF_INET maps to sockaddr_in
> AF_INET6 maps to sockaddr_in6
>
> This makes for a relatively convenient way to store addresses
> in a structure that also identifies them. For the address families
> that we don't have a structure for, "struct sockaddr" can carry the
> address and if that doesn't fit, "struct sockaddr_storage" will.
>
>
> And while the structure was designed to support the kernel socket
> interface, it can be used elsewhere too.
>
> For all that these do, we don't have anything that defines a
> structure or address family for ethernet - there's no AF_ETHER
> or AF_802_3 and nor is there a "struct sockaddr_ether".
>
> What I'd like to propose is to create the following:
>
> #define AF_802_3 31
>
> struct sockaddr_ether {
> sa_family_t se_family;
> uint8_t se_reserved[6];
> uint8_t se_addr[6];
> };
>
> ...the se_reserved is indecision about whether or not there
> should be se_sap, se_vlan, etc included here.
>
> NOTE: there are no plans to introduce 802.3 or ethernet sockets,
> although whatever this does should not preclude that from being
> easily possible.
>
> Thoughts?
>
> Darren
>
> _______________________________________________
> networking-discuss mailing list
> [email protected]
>
In BSD and Linux, 31 is defined for AF_BLUETOOTH, I suggest to reserve
it for future Solaris Bluetooth protocol stack.
- Michael
_______________________________________________
networking-discuss mailing list
[email protected]
