> I have started working on CR 6745288. This CR enhances libdladm by
> allowing users of libdladm to create handles and pass to libdladm
> function. This reduces the number of open(DLD_CONTROL_DEV) calls.
>
> I have started out with the following structure for the handle:
>
> struct dladm_handle {
> int dld_fd; /* file handle for DLD_CONTROL_DEV */
> datalink_id_t dld_linkid;
> char dld_linkname[MAXLINKNAMELEN];
> };
>
> I've noticed that there are a lot of calls to dladm_name2info() and
> dladm_datalink_id2info(), both of which return the flags, class, and
> media associated with the link.
Before going too far with handles, I think it's important to step back and
look at the semantics needed by libdladm consumers. In this case, do
consumers usually do things repeatedly on a single link, or do they
iterate over a set of links? (Or is this merely a cache? If so, how is
the cache kept current?)
More generally, the priority should be simplifying libdladm callers (with
the implementation of libdladm itself a distant secondary concern). For
instance, ideally, dladm should be a trivial wrapper around libdladm that
parses its input arguments to build the arguments to pass to a few
libdladm functions, then outputs appropriate error messages. Right now it
has a whole bunch of other stuff which suggests that the library/command
split is in the wrong place.
--
meem
