Cathy Zhou wrote:
> Sebastien Roy wrote:
>> Cathy Zhou wrote:
>>> I don't agree that tunnel name generation should be done in the tun
>>> driver. Note that this tunnel name cannot have conflict with any link
>>> name (including other types of links and even persistent-only links
>>> that don't exist in the kernel). I think the name generation should
>>> be done in linkmgmtd which knows every link name.
>>>
>>> One solution is to have another dladm door call API to request a link
>>> name.
>>
>> Good point. I agree with your premise, but I think there are some
>> technical details to work out with this approach beyond agreeing to
>> use the door to linkmgmtd. For example, there are three specific
>> types of IP tunnels, each of which utilize a different default naming
>> scheme ("ip.tun#", "ip6.tun#", "ip.6to4tun#"). I do not expect
>> linkmgmtd to know specifics of sub-types of a particular link class.
>>
>> As such, would it be appropriate for linkmgmt to simply dole out
>> unused PPAs rather than unused link names? For example, if libiptun
>> needs the next available link name for a 6to4 tunnel, it could do:
>>
>> status = dladm_get_nextppa("ip.6to4tun", &ppa);
>>
>> This would result in a conversation with linkmgmtd, which will have
>> some way to efficiently determine the next available PPA and return it.
>>
>> Any other ideas?
>>
> It seems that we need a function like dladm_init_namespace("ip.6to4tun",
> min, max), so that linkmgmtd knows that this prefix is special and do
> some special processing when creating each <linkname, linkid> mapping pair.
>
I will add both to the next version of the link ID management API document.
thanks,
Dan
