A very belated opinion for PSARC review.  Please review by 09/11/2009.

-Seb

-------------- next part --------------

 sun
   microsystems              Systems Architecture Committee

_________________________________________________________________

Subject:       Clearview Nemo Unification and Vanity Naming

Submitted by:  Cathy Zhou

File:          PSARC/2006/499/opinion.ms

Date:          July 18th, 2007

Committee:     Bill Sommerfeld (opinion written by Sebastien
               Roy),  Kais  Belgaied,  James  Carlson,  Mark
               Carlson

Product Approval Committee:

               Solaris PAC
               solaris-pac-opinion at sun.com

1.  Summary

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 adminis-
tratively  assign  names  to  datalinks,   and   to   rename
datalinks.

2.  Decision & Precedence Information

The project is approved as specified in references [1], [2],
and [3].

The project may be delivered in a minor release  of  Solaris
as part of the ON consolidataion.

The project depends on the following other projects and  may
not be delivered before them.

     PSARC/2003/246
          File System Driven Device Naming

     PSARC/2004/571
          Nemo - a.k.a. GLD v3

     PSARC/2006/358
          VLAN Observability Enhancement

PSARC/2006/499               Copyright 2007 Sun Microsystems

                           - 2 -

     PSARC/2006/436
          Public DLPI Library

3.  Interfaces

The project exports the following interfaces.

_______________________________________________________________________________
|                             Interfaces Exported                             |
|____________________________|_______________________|________________________|
|Interface                   |  Classification       |  Comments              |
|____________________________|_______________________|________________________|
|/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 <key>     |  Obsolete             |  Replaced by link name.|
|dladm -d <dev> options      |  Obsolete             |  Replaced by           |
|                            |                       |  -l <link> 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()         |                       |                        |
|____________________________|_______________________|________________________|

PSARC/2006/499               Copyright 2007 Sun Microsystems

                           - 3 -

The project imports the following interfaces.

_______________________________________________________
|                 Interfaces Imported                 |
|____________|_______________________|________________|
|Interface   |  Classification       |  Comments      |
|____________|_______________________|________________|
|libdlpi     |  Committed            |  PSARC/2006/436|
|devname APIs|  Consolidation Private|  PSARC/2003/246|
|____________|_______________________|________________|

4.  Opinion

4.1.  Verbose Link Descriptions

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  charac-
teristics  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 dis-
tinct from the IP interface name.  This solution will not be
part  of this project.  Section 6 contains advisory informa-
tion for the implementation of this feature.

4.2.  Inetd for Door Servers

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.

PSARC/2006/499               Copyright 2007 Sun Microsystems

                           - 4 -

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 imple-
mentation of such a feature.

5.  Minority Opinion(s)

None

6.  Advisory Information

6.1.  dladm Link Descriptions

The project's management should fund a project to  add  link
descriptions  to  the dladm(1M) command as discussed in sec-
tion 4.1.  The descriptions should be  arbitrary  text  that
can be set by the adminitrator.

6.2.  Door Server Delegated Restarter

The 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 mul-
titute of idle door server daemons waiting  for  door  calls
from clients.

7.  Appendices

7.1.  Appendix A: Technical Changes Required

None

7.2.  Appendix B: Technical Changes Advised

None

7.3.  Appendix C: Reference Material

Unless stated otherwise, path names are relative to the case
directory PSARC/2006/499.

     1.   Design Document
          File: commitment.materials/uv-design.pdf

     2.   PSARC 20 Questions
          File: commitment.materials/uv_20q.txt

     3.   Datalink ID Management API Design
          File: commitment.materials/link_id_management.pdf

PSARC/2006/499               Copyright 2007 Sun Microsystems

Reply via email to