Dan Groves wrote:
> 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);
>
Today, dladm (and its libraries) sends ioctls to different drivers (aggr,
dld) to manipulate active configuration (for example, to create/modify an
aggregation, or set link properties), are you going to replace that?
I would assume that the APIs above is only doing datalink configuration
persistence. Also, the linkid allocation, release for both active links and
persistent links because linkname, linkids need to be unique in both spaces.
> 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.
Stored where? If it is persistent configuration, I understand that you store
it in the configuration repository, otherwise, if it is temporary
configuration, are you going to inform the kernel to do relevant operation?
Or just store them in the application daemon. If it is only the latter, I
don't think it is complete. The former looks like a good idea except it
needs to understand the syntax of each link field to send the right ioctl to
the right driver.
What do you think?
Thanks
- Cathy
> 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
>
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris.org
