Hello, Cathy, I added some information inline.
BTW, they are DLDIOCHOLDVLAN/DLDIOCRELEVLAN. Best, Donghai. ----- Original Message ----- From: Cathy Zhou <[email protected]> Date: Wednesday, April 11, 2007 7:58 pm Subject: ioctl DLDIOC_HOLDVLAN/DLDIOC_RELEVLAN To: Dong-Hai Han <Donghai.Han at Sun.COM>, James Carlson <James.D.Carlson at Sun.COM>, clearview-discuss <clearview-discuss at opensolaris.org>, Erik.Nordmark at Sun.COM > Hi, > > I'd like to get opinion from you on the potential removal of > DLDIOC_HOLDVLAN/DLDIOC_RELEVLAN ioctls as part of the Clearview > vanity naming support. > > As I understood from reading the code and talking to Dong Hai, the > DLDIOC_HOLDVLAN and DLDIOC_RELEVLAN ioctls are introduced for two > requirement of the stack-instance project: > > a. It is needed to have this link created (specifically, the > dls_vlan_t created), so that that structure can keep the zoneid information. > This information is then used by dladm to lookup the zoneid of a link, > when one tries to use dladm to change or get the zoneid of a link. Yes, get it created (if it is not already there) is one purpose, furthermore, it is more important to "hold" the link on behalf of the zone, note that the zone could just "own" the datalink and not using it at all, thus we hold a reference to keep the dls_vlan_t alive. > > b. It is also needed to create the devfs minor node of a VLAN link > (if the assgined physical name is a ppa hack name), so that we can create a > symbol link of the /dev node in the local zone. Yes, currently it is done as part of the DLDIOCHOLDVLAN operation for VLANs, if Clearview can meet the create/hold requirement, this one is easy, just like you pointed out below. > As part of vanity naming, we could do an implied "dladm create- > vlan" as part of exclusive-zone boot, and that VLAN's devfs minor node will > be > created then, therefore requirement (b) is no longer needed. What is the "implied dladm create-vlan"? doesn't it require some similar operations? > But I am not sure where and how to remove requirement (a). We could > look up the <zoneid, link> mapping using the zone interface (every zone > keeps a list of link name), but it means that we have to walk all the zones > to > get the corrct information. In the case of lots of zones, that might be a > performance pain. > > What's your suggestion? > > Thanks > - Cathy >
