Hi Cathy,
Cathy Zhou wrote:
> Hi Dan,
>
> I am done with the simple case of the the kernel door upcall and start to
> work on the libdladm door calls.
>
> First, do we agree that dladm_datalink_xxx() function will only be used to
> persistent link configuration, with the exception that we also needs
> function to allocate and free linkids for temporary links? If so, to get
> the linkid of a temporarily created links, is the below process right?
>
> dladm_datalink_create(name, class, &dh);
> dladm_datalink_commit(dh);
> dladm_datalink_get_id(name, &linkid);
>
> It seems complicated.
>
Yes it does seem complicated. Maybe we could do something like this
instead:
dladm_get_empty_dlconf(&dh);
dladm_set_dlconf_field(dh, "name", "net0");
dladm_set_dlconf_field(dh, "device", "bge0");
dladm_set_dlconf_field(dh, "class", "aggr");
dladm_commit_dlconf(dh, TEMP);
dladm_get_linkid("net0", &linkid);
There's more function calls, but I think this approach solves a few
different problems.
Let me explain first what's going with this approach.
This approach is similar to how X programming works (or used to work,
it's been many years since I've done X programming). When you want to
draw something on the screen, you create a Widget. The Widget is a data
structure that holds information about what it is you want to draw.
When you create the Widget, the X server doesn't draw anything on the
screen. You set options on the Widget, and then you tell the X server
to draw the Widget.
The first thing in my example is dladm_get_empty_dlconf. This get you
an empty data link configuration structure. At this point there has
been no link name to link id mapping created.
Then you set the fields of the structure. At a minimum for this
version, when you want to create a new link you need to set name and
class (and possibly physical device). Right now we're talking about
having different ID spaces for different classes of links, i.e.
aggregations have a particular range, and other links have another
range. So right now with the create function, you need to know the
link's name and class. What if we need to know more in the future?
Would we change the create function? This method we don't need to
change the function signature, we just add more dladm_set_dlconf_field
calls to the API's user.
I think this also provides a solution to the persistent vs. temporary
link problem. When dladm_commit_dlconf is called in my example, two
things happen. The link ID to name mapping is created (if one does not
exist for this link), and the link configuration structure is stored.
The mapping and the storage are either persistent or temporary based on
the argument to the function. If it is temporary, neither the mapping
nor the configuration persist across reboots. If it is persistent, then
they survive across reboots.
What happens if an administrator wants to have both a persistent and a
temporary configuration? We could assume the temporary configuration
takes precedence over the persistent configuration when both exist.
While this is a radical change, I think it makes more sense, and is more
extensible. What do you think?
> Second, I'd like to add an argument to indicate whether the lock is read or
> write in the dladm_datalink_lock() function.
>
Sure.
> Third, I am not sure what's conclusion that whether the
> dladm_datalink_create() takes the argument to indicate a link is
> persistent or temporary, or dladm_datalink_commit() takes that argument?
>
> Please let me know.
>
Yesterday I was working on incorporating the feedback I received from
you and Meem before the break. I came up with a solution to the
problem, but now I don't think it is a good solution. I think the
solution above is a better one. Let me know what you think. If you
want me to pursue this new idea, I will.
thanks,
Dan
