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.
Thanks
- Cathy
