> with answers to semi-frequent questions like "how do I
> find my MAC address in C?"
Indeed -- though ideally the answer to that particular question shouldn't
require a low-level interface like DLPI at all[1].
> I can't stop myself from asking questions like "how could porting a
> client for that be made simpler?"
... and it's a good question to ask. However, as Jim has mentioned,
AF_LINK on Solaris may not be the answer either.
> And then there's Style 1 vs Style 2, etc. I haven't looked enough to
> be sure, but I think there's more consensus on what link access should
> look like with the sockets interface than with DLPI.
The distinction between DL_STYLE1 and DL_STYLE2 is completely hidden by
the proposed libdlpi API. Link access seems pretty well-defined to me,
but I may be misunderstanding what you mean. (Not that I'm trying to
defend DLPI.)
> if libdlpi were to be regarded as a public interface, it might be
> at least helpful across platforms using DLPI if there were some
> consideration as to whether libdlpi could be implemented on other such
> platforms, help to minimize differences seen by its users, etc.
I believe that libdlpi should indeed be portable to other Unix flavors
that support DLPI.
----
[1] That said, we have made doing this from DLPI much, much easier.
Case in point: Sagun's webrev includes an overhaul of iscistgtd to use
libdlpi to do this, reducing 175 lines of logic down to just:
boolean_t
grab_address(const char *ifname, uchar_t **addr, size_t *lp)
{
int retval;
dlpi_handle_t dh;
if (dlpi_open(ifname, &dh, 0) != DLPI_SUCCESS)
return (B_FALSE);
retval = dlpi_get_physaddr(dh, DL_CURR_PHYS_ADDR, *addr, lp);
dlpi_close(dh);
return (retval == DLPI_SUCCESS);
}
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
