.de Sc \\s-1\\$1\\s0\\$2 .. .ds cA 2006/499 .ds aR \s-1PSARC\s0 .LP .so ../../amac .Co .ds LF \fI\*(aR/\*(cA\fP .ds RF \fICopyright 2007 Sun Microsystems\fP .if n .ds CF .IP \fBSubject:\fP 15 Clearview Nemo Unification and Vanity Naming .IP "\fBSubmitted by:\fP" 15 Cathy Zhou .IP \fBFile:\fP 15 \*(aR/\*(cA/opinion.ms .IP \fBDate:\fP 15 July 18th, 2007 .IP "\fBCommittee:\fP" 15 Bill Sommerfeld (opinion written by Sebastien Roy), Kais Belgaied, James Carlson, Mark Carlson .IP "\fBProduct Approval Committee:\fP" 15 Solaris PAC .br solaris-pac-opinion@sun.com .pn 2 .NH Summary .LP This is one of a series of projects under the PSARC/2005/132 umbrella case, "Clearview: Network Interface Coherence". This project unifies all Ethernet drivers under the Nemo framework introduced by PSARC/2004/571, bringing support for Nemo features such as VLANs and link aggregations to all Ethernet links. It also introduces the ability to administratively assign names to datalinks, and to rename datalinks. .NH Decision & Precedence Information .LP The project is approved as specified in references [1], [2], and [3]. .LP The project may be delivered in a minor release of Solaris as part of the ON consolidataion. .LP The project depends on the following other projects and may not be delivered before them. .RS .IP \*(aR/2003/246 File System Driven Device Naming .IP \*(aR/2004/571 Nemo - a.k.a. GLD v3 .IP \*(aR/2006/358 VLAN Observability Enhancement .IP \*(aR/2006/436 Public DLPI Library .RE .NH Interfaces .LP The project exports the following interfaces. .if n .ne 8 .if t .ne 3 .TS H box; c s s l | l | l. Interfaces Exported _ Interface Classification Comments _ .TH /dev/net Committed [1] section 6.2.1 dlpi_walk() Committed New libdlpi function. [1] section 3.1.6 dladm rename-link Committed [1] section 4.3.1 dladm create-vlan Committed [1] section 4.1.4 delete-vlan show-vlan dladm show-phys Committed [1] section 4.1.2 delete-phys autopush link property Committed [1] section 4.3.4 dladm show-dev Obsolete [1] section 4.1.3 dladm aggregation Obsolete Replaced by link name. dladm -d options Obsolete Replaced by -l options. datalink_id_t Consolidation Private [3] Datalink ID Management API Consolidation Private [3] libdladm changes Consolidation Private [1] DLIOCVLANINFO Consolidation Private [1] section 6.1.4 DLPI_DEVONLY Consolidation Private [2] section 7 librcm.so Consolidation Private Moved from /usr/lib to /lib MAC_CAPAB_* MAC Capabilities Project Private [1] section 7.1.4 mc_open(), mc_close() Project Private [1] section 7.1.3 mac_perstream_open() Project Private [1] section 7.1 RCM_RESOURCE_LINK_NEW Project Private [1] section 6.2.7 /etc/.dlmgmtd_door Project Private Door file for dlmgmtd softmac_create() Project Private New softmac kernel API softmac_destroy() softmac_hold_link() softmac_rele_link() .TE .LP The project imports the following interfaces. .if n .ne 8 .if t .ne 3 .TS H box; c s s l | l | l. Interfaces Imported _ Interface Classification Comments _ .TH libdlpi Committed PSARC/2006/436 devname APIs Consolidation Private PSARC/2003/246 .TE .NH Opinion .LP .NH 2 Verbose Link Descriptions .LP While this case introduces the concept of flexible datalink names that could have meaning in a given context, it does not solve the greater problem of mapping a given physical network link to its attachment to the network (e.g. PCI slot label, or other verbose description of the physical characteristics of the attachment). Datalink names have a strict syntax (described in the NOTES section of dlpi(7P), and thus cannot contain arbitrary text. The committee and project team agreed that the link name is likely not the right vehicle for verbose descriptions. A possible and more feasible solution for this would be to add a link description to dladm separate from the link name. One member noted that this would be in line with SNMP MIB-2's ifDescr OID describing an IP interface, which is distinct from the IP interface name. This solution will not be part of this project. Section 6 contains advisory information for the implementation of this feature. .NH 2 Inetd for Door Servers .LP The committee noted that the dlmgmtd door server being introduced by this project may be idle when not answering door calls, which is likely to be the majority of the time, yet it is always running. It is likely one of many in a class of daemons that similarly sit idle while waiting for a door client to call. There is system overhead to having these processes constantly running yet idle. This "class" of daemon is similar to the set of network server daemons that sit idle while waiting for a client to establish a connection. For network servers, the problem was solved long ago with the introduction of the inetd(1M) daemon, which starts services on-demand upon connection establishment and acts as the delegated restarter for those services. This general approach could be applied to door servers. A single restarter could be responsible for starting services upon receiving door calls associated with those services. Section 6 contains advisory information regarding the implementation of such a feature. .NH Minority Opinion(s) .LP None .NH Advisory Information .LP .NH 2 dladm Link Descriptions .LP The project's management should fund a project to add link descriptions to the dladm(1M) command as discussed in section 4.1. The descriptions should be arbitrary text that can be set by the adminitrator. .NH 2 Door Server Delegated Restarter .LP The Solaris PAC is advised to fund a project to investigate and potentially implement the solution to the problem described in section 4.2. Specifically, a door server restarter is needed to reduce the overhead associated with having a multitute of idle door server daemons waiting for door calls from clients. .NH Appendices .NH 2 Appendix A: Technical Changes Required .LP None .NH 2 Appendix B: Technical Changes Advised .LP None .NH 2 Appendix C: Reference Material .LP Unless stated otherwise, path names are relative to the case directory \*(aR/\*(cA. .RS .IP 1. Design Document .br File: commitment.materials/uv-design.pdf .IP 2. PSARC 20 Questions .br File: commitment.materials/uv_20q.txt .IP 3. Datalink ID Management API Design .br File: commitment.materials/link_id_management.pdf .RE