I learned that the datalink linkid and link name are not always
one-to-one mappings. So, to simplify things, I am going to start with
the handle containing just the file descriptor to DLD_CONTROL_DEV.
Other properties can be added to the handle later as seen fit. Having
just the file handle also allows the handle to be opened just once for
walks rather than opening a different handle for each datalink.
Anurag
Peter Memishian wrote:
> > 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.
>
>
