From sacadmin Fri Jun 10 16:21:30 2005 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5ANLUs0014275; Fri, 10 Jun 2005 16:21:30 -0700 (PDT) Received: (from kais@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id j5ANLUbJ014271; Fri, 10 Jun 2005 16:21:30 -0700 (PDT) Date: Fri, 10 Jun 2005 16:21:30 -0700 (PDT) From: Kais Belgaied Message-Id: <200506102321.j5ANLUbJ014271@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: gld-iteam@sun.com, nicolas.droux@sun.com Subject: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] Status: RO Content-Length: 6750 Subject: PSARC FastTrack [06/17/2005]: Nemo drivers interface simplification Template Version: @(#)sac_nextcase 1.55 08/11/04 SMI Copyright 2005 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: Nemo drivers interface simplification 1.2. Name of Document Author/Supplier: Author: Nicolas Droux 1.3 Date of This Document: 10 June, 2005 4. Technical Description Overview -------- This case proposes a set of changes to Nemo (PSARC/2004/571) to address backward compatibility issues that were found post integration of the project. This case does not take away from the key functionality of Nemo (generic VLAN support, link aggregation, and adaptive interrupt blanking). The proposal seeks patch/micro binding. Since PSARC/2004/571 (that was approved for a micro/release binding), hasn't yet been delivered in a micro release, the team plans to ship the version of PSARC/2004/571 ammended by this case, and no prior versions. diff-marked man pages and mac.h are attached in the case directory for reference. Introduction ------------ Nemo (PSARC 2004/271) introduced a new architecture for network device drivers. The datalink nodes for Nemo drivers are created as nodes of the pseudo driver dld. For example, prior to Nemo, a DDI_NT_NET node for device bge0 appeared as a node of the bge driver in /dev: bge0 -> ../devices/pci@0,0/pci1022,7450@a/pci10f1,2885@9:bge0 With Nemo, the same node would appear as a node of dld: bge0 -> ../devices/pseudo/dld@0:bge0 Under Nemo, there is therefore no longer a one-to-one mapping between network interface names and device driver names. It was found after the project integrated that other components of Solaris, and possibly 3rd party software, rely on this one-to-one mapping. For example, as captured by bug 6253542, the major driver name is used to specify to autopush where STREAMS modules must be inserted. This causes backward compatibility problems when autopush is configured on top of a Nemo device, since the driver name seen by autopush will be "dld" instead of the expected driver name (e.g. "bge"), which would cause modules to not be inserted on the STREAM as expected. Another class of consumers that depend on this one-to-one mapping and that are affected are kernel components that walk the queues that are on a STREAM under them, and use the mi_idnum and mi_idname fields of the module_info structure associated with the last queue found to identify the name of the device. For current Nemo device, this name will be always "dld" instead of the expected device driver name (e.g. "bge") which affects backward compatibility for such consumers. Even though it might be possible to fix these consumers one by one, there would be still a risk of breaking backward compatibility for 3rd party software that rely on this one-to-one mapping. This document describes a suggested long term and final fix that addresses all of these issues. Proposal -------- We are proposing to address the problem introduced above by making the following changes to Nemo: 1) Nemo will create device nodes using the devinfo of the underlying driver instead of using the dld devinfo. This will restore backward compatibility for consumers that rely on the one-to-one mapping between interface and driver names. 2) Nodes in /dev will be created when the drivers register with Nemo, i.e. when instances of Nemo devices are attached. Nemo drivers are not required to create their own nodes. 3) Due to 1) and 2), separate nodes for VLANs in /dev are no longer needed, and it is possible to automatically create VLAN interfaces when a style-2 attach is done on the device with a PPA value of VID*1000+instance. This corresponds to the VLAN administration model implemented by the Cassini driver as well as the pre-Nemo bge driver. The dladm create-vlan and delete-vlan subcommands are therefore no longer needed and can be removed. 4) Since /dev nodes for devices are automatically created, and no separate nodes are needed for VLANs, the datalink-init and datalink SMF services, the dladm init-link and up-link subcommands, and the datalink.conf configuration file are no longer needed. Further, the aggregation SMF service is no longer needed as a separate service, and we propose that the dladm up-aggr subcommand be invoked directly from the network/physical service. 5) MAC drivers will become STREAMS driver. The new DDI_NT_MAC type that was introduced as part of the original Nemo case (2004/571) will be removed. The STREAMS entry points (open(9E), close(9E), put(9E), srv(9E)) will be implemented by Nemo on behalf of the the device driver. Interface Changes ----------------- * In summary, here are the proposed changes to dladm(1M) (Evolving): Current subcommand| Proposed | Purpose ------------------|-------------------|--------------------------- create-vlan | [removed] | Creates a VLAN /dev link delete-vlan | [removed] | Deletes a VLAN /dev link init-link | [removed] | Populates /etc/datalink.conf up-link | [removed] | Creates /dev links during boot Note that none of these interfaces have been released. * The proposed changes to other components of the original Nemo case (Project Private) Component | Proposed | Purpose ------------------|-------------------|--------------------------- /etc/datalink.conf| [removed] | Used by up-link to create | | datalink nodes in /dev datalink-init svc | [removed] | service used to invoke | | dladm init-link datalink svc | [removed] | service used to invoke | | dladm up-link aggregation svc | [removed] | service used to invoke | | dladm up-aggr, instead invoke | | from network/physical DDI_NT_MAC | [removed] | obsolete * The following MAC interfaces changes are proposed: . two consolidation private routines are introduced: void mac_init_ops(struct dev_ops *, const char *); void mac_fini_ops(struct dev_ops *); . Each Nemo driver is required to performed the following * call mac_init_ops(&dev_ops, module_name) before calling mod_install( Date: Fri, 10 Jun 2005 16:36:35 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kais Belgaied CC: PSARC@sac.sfbay.sun.com, gld-iteam@sun.com, nicolas.droux@sun.com Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] References: <200506102321.j5ANLUbJ014271@sac.sfbay.sun.com> In-Reply-To: <200506102321.j5ANLUbJ014271@sac.sfbay.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 671 > Further, the aggregation SMF service is no longer needed as a > separate service, and we propose that the dladm up-aggr subcommand > be invoked directly from the network/physical service. Please note the intention of the netadm project to support multiple instances of the network/physical service. When multiple instances are enabled (which will be a common situation) should each instance invoke dladm up-aggr as it is started? When no network/physical instances are enabled (which will be an unusual but fully supported situation) will data link services still be usable? Is there another service that can be used a dependency for data link consumers? From sacadmin Fri Jun 10 16:42:17 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5ANgHs0015326; Fri, 10 Jun 2005 16:42:17 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5ANfoPu015628; Fri, 10 Jun 2005 16:41:50 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id j5ANfmMh010420; Fri, 10 Jun 2005 16:41:49 -0700 (PDT) Message-ID: <42AA253C.4050305@sun.com> Date: Fri, 10 Jun 2005 16:41:48 -0700 From: David Kahn User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kais Belgaied CC: PSARC@sac.sfbay.sun.com, gld-iteam@sun.com, nicolas.droux@sun.com Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 611 Kais Belgaied wrote: > 3) Due to 1) and 2), separate nodes for VLANs in /dev are no longer > needed, and it is possible to automatically create VLAN interfaces > when a style-2 attach is done on the device with a PPA value of > VID*1000+instance. This corresponds to the VLAN administration > model implemented by the Cassini driver as well as the pre-Nemo bge > driver. The dladm create-vlan and delete-vlan subcommands are > therefore no longer needed and can be removed. What does "PPA value of VID*1000+instance" mean? Can't we just push the vlan streams module when needed? -David From sacadmin Fri Jun 10 17:00:18 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.228.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5B00Is0017465; Fri, 10 Jun 2005 17:00:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5ANxod8759687 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 10 Jun 2005 16:59:50 -0700 (PDT) Date: Fri, 10 Jun 2005 16:59:50 -0700 (PDT) From: Nicolas Droux Sender: Nicolas.Droux@eng.sun.com To: David Kahn cc: Kais Belgaied , , Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] In-Reply-To: <42AA253C.4050305@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Content-Length: 1040 On Fri, 10 Jun 2005, David Kahn wrote: > > Kais Belgaied wrote: > > > 3) Due to 1) and 2), separate nodes for VLANs in /dev are no longer > > needed, and it is possible to automatically create VLAN interfaces > > when a style-2 attach is done on the device with a PPA value of > > VID*1000+instance. This corresponds to the VLAN administration > > model implemented by the Cassini driver as well as the pre-Nemo bge > > driver. The dladm create-vlan and delete-vlan subcommands are > > therefore no longer needed and can be removed. > > What does "PPA value of VID*1000+instance" mean? It means that if you want to plumb an interface for a VLAN with VID 123 on top of a bge device instance 1, you'd plumb bge123001. This is currently what is used for ce and bge in S10, and also the current datalink name created by Nemo. > Can't we just push the vlan streams module when needed? There's no such thing in the Nemo architecture. Nicolas. -- Nicolas Droux Solaris Core Networking Technologies Sun Microsystems, Inc. From sacadmin Fri Jun 10 19:34:18 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5B2YIs0022663; Fri, 10 Jun 2005 19:34:18 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5B2XpPu027813; Fri, 10 Jun 2005 19:33:51 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id j5B2XnMh014878; Fri, 10 Jun 2005 19:33:49 -0700 (PDT) Message-ID: <42AA4D8C.3060006@sun.com> Date: Fri, 10 Jun 2005 19:33:48 -0700 From: David Kahn User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Droux CC: Kais Belgaied , PSARC@sac.sfbay.sun.com, gld-iteam@sun.com Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 505 Nicolas Droux wrote: >>What does "PPA value of VID*1000+instance" mean? > > > It means that if you want to plumb an interface for a VLAN with VID 123 on > top of a bge device instance 1, you'd plumb bge123001. This is currently > what is used for ce and bge in S10, and also the current datalink name > created by Nemo. Do you expect all network drivers to do this? >>Can't we just push the vlan streams module when needed? > > > There's no such thing in the Nemo architecture. Why not? -David From sacadmin Fri Jun 10 20:01:32 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5B31Ws0024943; Fri, 10 Jun 2005 20:01:32 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j5B314OZ008954; Fri, 10 Jun 2005 23:01:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j5B3149o008951; Fri, 10 Jun 2005 23:01:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17066.21488.573795.874728@gargle.gargle.HOWL> Date: Fri, 10 Jun 2005 23:01:04 -0400 From: James Carlson To: David Kahn Cc: Nicolas Droux , Kais Belgaied , PSARC@sac.sfbay.sun.com, gld-iteam@Sun.COM Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] In-Reply-To: David Kahn's message of 10 June 2005 19:33:48 References: <42AA4D8C.3060006@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 642 David Kahn writes: > > There's no such thing in the Nemo architecture. > > Why not? It's a fair question, but perhaps not related to this case. The really unfortunate expectation of ID*1000+PPA was created by PSARC 2000/147. We're stuck with it until the Clearview project can get us something better. This case actually makes it *easier* for Clearview to do its work, so it's a good step in the right direction. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Jun 10 21:12:35 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5B4CZs0027437; Fri, 10 Jun 2005 21:12:35 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5B4C7Pu013707; Fri, 10 Jun 2005 21:12:07 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id j5B4C5Mh016962; Fri, 10 Jun 2005 21:12:06 -0700 (PDT) Message-ID: <42AA6495.5050802@sun.com> Date: Fri, 10 Jun 2005 21:12:05 -0700 From: David Kahn User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: Nicolas Droux , Kais Belgaied , PSARC@sac.sfbay.sun.com, gld-iteam@sun.com Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] References: <42AA4D8C.3060006@sun.com> <17066.21488.573795.874728@gargle.gargle.HOWL> In-Reply-To: <17066.21488.573795.874728@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 850 James Carlson wrote: > David Kahn writes: > >>>There's no such thing in the Nemo architecture. >> >>Why not? > > > It's a fair question, but perhaps not related to this case. > > The really unfortunate expectation of ID*1000+PPA was created by PSARC > 2000/147. We're stuck with it until the Clearview project can get us > something better. > > This case actually makes it *easier* for Clearview to do its work, so > it's a good step in the right direction. > Fair enough, I'm just wondering if there's an expectation that Nemo will work with 3rd party drivers, and thus put requirements on the way they export their instances, etc. It's fairly apparent that there wasn't a lot of testing done before the case was approved, and that's why it's back at PSARC requesting changes. (At least from what I can tell from the fast-track.) -David From sacadmin Mon Jun 13 08:38:27 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.106.105] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5DFcRs0026741; Mon, 13 Jun 2005 08:38:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5DFbwkR506488 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 13 Jun 2005 08:37:58 -0700 (PDT) Date: Mon, 13 Jun 2005 08:37:57 -0700 (PDT) From: Nicolas Droux Sender: Nicolas.Droux@eng.sun.com To: David Kahn cc: Kais Belgaied , , Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] In-Reply-To: <42AA4D8C.3060006@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Content-Length: 791 On Fri, 10 Jun 2005, David Kahn wrote: > > > Nicolas Droux wrote: > > >>What does "PPA value of VID*1000+instance" mean? > > > > > > It means that if you want to plumb an interface for a VLAN with VID 123 on > > top of a bge device instance 1, you'd plumb bge123001. This is currently > > what is used for ce and bge in S10, and also the current datalink name > > created by Nemo. > > Do you expect all network drivers to do this? No. This is how VLAN interfaces are plumbed. > > >>Can't we just push the vlan streams module when needed? > > > > > > There's no such thing in the Nemo architecture. > > Why not? Because it's not how VLANs are implemented by Nemo, see PSARC 2004/571. Nicolas. > > -David > -- Nicolas Droux Solaris Core Networking Technologies Sun Microsystems, Inc. From sacadmin Mon Jun 13 08:41:24 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.106.105] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5DFfOs0027326; Mon, 13 Jun 2005 08:41:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5DFetEW507374 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 13 Jun 2005 08:40:55 -0700 (PDT) Date: Mon, 13 Jun 2005 08:40:55 -0700 (PDT) From: Nicolas Droux Sender: Nicolas.Droux@eng.sun.com To: David Kahn cc: James Carlson , Kais Belgaied , , Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] In-Reply-To: <42AA6495.5050802@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Content-Length: 517 On Fri, 10 Jun 2005, David Kahn wrote: > Fair enough, I'm just wondering if there's an expectation that > Nemo will work with 3rd party drivers, and thus put requirements > on the way they export their instances, etc. Of course Nemo will work with 3rd party drivers, that's the plan for the longer term. The semantics associated with the PPA value for VLAN is transparent to device drivers, which is handled by Nemo itself. Nicolas. -- Nicolas Droux Solaris Core Networking Technologies Sun Microsystems, Inc. From sacadmin Tue Jun 14 14:32:30 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5ELWUs0016759; Tue, 14 Jun 2005 14:32:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5ELW06m228029 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Jun 2005 14:32:00 -0700 (PDT) Date: Tue, 14 Jun 2005 14:32:00 -0700 (PDT) From: Nicolas Droux Sender: Nicolas.Droux@eng.sun.com To: Mike Ditto cc: Kais Belgaied , , Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] In-Reply-To: <42AA2403.6030300@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Content-Length: 1055 On Fri, 10 Jun 2005, Mike Ditto wrote: > > Further, the aggregation SMF service is no longer needed as a > > separate service, and we propose that the dladm up-aggr subcommand > > be invoked directly from the network/physical service. > > Please note the intention of the netadm project to support multiple > instances of the network/physical service. > > When multiple instances are enabled (which will be a common situation) > should each instance invoke dladm up-aggr as it is started? Yes, and the aggregations would be brought up only once. > When no network/physical instances are enabled (which will be an > unusual but fully supported situation) will data link services > still be usable? Aggregations would not be available to these link services in that case. > Is there another service that can be used a dependency for data link > consumers? With the approach we're proposing here, we no longer rely on a separate service for datalinks. Nicolas. -- Nicolas Droux Solaris Core Networking Technologies Sun Microsystems, Inc. From sacadmin Wed Jun 15 10:40:51 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.228.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FHeos0025229 for ; Wed, 15 Jun 2005 10:40:50 -0700 (PDT) Received: from [129.146.109.100] (d-mpk17-109-100.SFBay.Sun.COM [129.146.109.100]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5FHeLgr904060; Wed, 15 Jun 2005 10:40:21 -0700 (PDT) Message-ID: <42B067FA.7010804@Sun.COM> Date: Wed, 15 Jun 2005 10:40:10 -0700 From: Kais Belgaied Reply-To: Kais.Belgaied@Sun.COM User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20050502 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: PSARC@sac.sfbay.sun.com CC: Nicolas Droux , gld-iteam@Sun.COM Subject: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 48 This case was approved in today's PSARC meeting From sacadmin Thu Jun 16 15:23:49 2005 Received: from sentry.sfbay.sun.com (sentry [129.146.157.28]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5GMNns0019805; Thu, 16 Jun 2005 15:23:49 -0700 (PDT) Received: from [192.9.61.246] (punchin-client-192-9-61-246.SFBay.Sun.COM [192.9.61.246]) by sentry.sfbay.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j5GMLQcD018547; Thu, 16 Jun 2005 15:21:27 -0700 (PDT) Message-ID: <42B1FBD2.90603@sun.com> Date: Thu, 16 Jun 2005 15:23:14 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Droux CC: Kais Belgaied , PSARC@sac.sfbay.sun.com, gld-iteam@sun.com Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1224 Nicolas Droux wrote: > With the approach we're proposing here, we no longer rely on a separate > service for datalinks. I know this project doesn't rely on it, but what about someone else who *wants* to make explicit their dependence on datalink service? If you want to configure, for example, a stealth (bridging) firewall and have the IP stack normally disabled, you should be able to fully bring up the datalink services to the point that you can use aggregations and then let the DLPI consumer (firewall software) use them. (This is hypothetical since we don't have any bridging firewall software that works on current Solaris, but we used to, and we probably will again soon.) But that being said, maybe this is not the right place to clean up the layering. Since both this project and wificonfig want to use svc:/network/physical as the SMF anchor for the datalink layer, maybe it should be the netadm project that moves over and creates another service to represent the network layer. As you pointed out, the name network/physical is a misnomer anyway. So I guess I have no objection except to leave this reminder that the layering violation should eventually be cleaned up by some project. -=] Mike [=- From sacadmin Thu Jun 16 16:23:55 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.58.37] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5GNNts0022956; Thu, 16 Jun 2005 16:23:55 -0700 (PDT) Received: from 129.146.108.198 (braveheart.SFBay.Sun.COM [129.146.108.198]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5GNNNhs586766; Thu, 16 Jun 2005 16:23:23 -0700 (PDT) Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] From: Darren J Moffat To: Mike Ditto Cc: Nicolas Droux , Kais Belgaied , PSARC@sac.sfbay.sun.com, gld-iteam@Sun.COM In-Reply-To: <42B1FBD2.90603@sun.com> References: <42B1FBD2.90603@sun.com> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1118964203.4006.133.camel@braveheart.sfbay.sun.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.316 Date: Thu, 16 Jun 2005 16:23:23 -0700 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 707 On Thu, 2005-06-16 at 15:23, Mike Ditto wrote: > svc:/network/physical as the SMF anchor for the datalink layer, maybe it > should be the netadm project that moves over and creates another service > to represent the network layer. As you pointed out, the name > network/physical is a misnomer anyway. That sounds reasonable to me, network/physical always sounded like link layer to me, network/ip or something else seems better for what netadm will do. > So I guess I have no objection except to leave this reminder that the > layering violation should eventually be cleaned up by some project. Indeed, hence both you and I commenting on the wificonfig case about /etc/inet/wifi ! -- Darren J Moffat From sacadmin Fri Jun 17 09:49:06 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5HGn6Eu001892; Fri, 17 Jun 2005 09:49:06 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j5HGn2sA012063; Fri, 17 Jun 2005 12:49:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j5HGn2D4012060; Fri, 17 Jun 2005 12:49:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17074.65278.827944.197033@gargle.gargle.HOWL> Date: Fri, 17 Jun 2005 12:49:02 -0400 From: James Carlson To: Mike Ditto Cc: Nicolas Droux , Kais Belgaied , PSARC@sac.sfbay.sun.com, gld-iteam@Sun.COM Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] In-Reply-To: Mike Ditto's message of 16 June 2005 15:23:14 References: <42B1FBD2.90603@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2297 Mike Ditto writes: > Nicolas Droux wrote: > > With the approach we're proposing here, we no longer rely on a separate > > service for datalinks. > > I know this project doesn't rely on it, but what about someone else who > *wants* to make explicit their dependence on datalink service? That sounds like it might be a new project. > If you want to configure, for example, a stealth (bridging) firewall and > have the IP stack normally disabled, you should be able to fully bring up > the datalink services to the point that you can use aggregations and then let > the DLPI consumer (firewall software) use them. (This is hypothetical > since we don't have any bridging firewall software that works on current > Solaris, but we used to, and we probably will again soon.) That, I think, is actually the definition of network/physical. However, I think the current state of this is just plain broken-as- designed. It makes no sense to me to assume that all interfaces are necessarily available right at boot time, or that any service anywhere should ever depend on "all datalinks are ready." I think it's the wrong decomposition of the problem. > But that being said, maybe this is not the right place to clean up the > layering. Since both this project and wificonfig want to use > svc:/network/physical as the SMF anchor for the datalink layer, maybe it > should be the netadm project that moves over and creates another service > to represent the network layer. As you pointed out, the name > network/physical is a misnomer anyway. Not really. The distinction is between virtual (i.e., loopback) and physical (i.e., palpable hardware) interfaces. The word "physical" in this instance doesn't refer to the OSI model, nor does it really need to. And the word "network" here doesn't refer to the "network" layer in OSI, but rather to networking in general, as opposed to (say) file systems. > So I guess I have no objection except to leave this reminder that the > layering violation should eventually be cleaned up by some project. "Layering violation" ... ? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Jun 17 16:53:41 2005 Received: from sentry.SFBay.Sun.COM (sentry [129.146.157.28]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5HNrfEu028351; Fri, 17 Jun 2005 16:53:41 -0700 (PDT) Received: from Sun.COM (sr1-umpk-06.SFBay.Sun.COM [129.146.11.166]) by sentry.SFBay.Sun.COM (8.12.11+Sun/8.12.11) with ESMTP id j5HNplK2002335; Fri, 17 Jun 2005 16:51:49 -0700 (PDT) Message-ID: <42B36282.70806@Sun.COM> Date: Fri, 17 Jun 2005 16:53:38 -0700 From: Mike Ditto User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: Nicolas Droux , Kais Belgaied , PSARC@sac.sfbay.sun.com, gld-iteam@Sun.COM Subject: Re: Nemo drivers interface simplification [PSARC/2005/365 Timeout: 06/17/2005] References: <42B1FBD2.90603@sun.com> <17074.65278.827944.197033@gargle.gargle.HOWL> In-Reply-To: <17074.65278.827944.197033@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2117 James Carlson wrote: > Mike Ditto writes: >>I know this project doesn't rely on it, but what about someone else who >>*wants* to make explicit their dependence on datalink service? > > That sounds like it might be a new project. I disagree; I think we now live in an SMF world and fundamental services must appear somewhere in the SMF graph. Two services should not be lumped into a single SMF service unless they are so tightly coupled in implementation or in usage model that they could never be used independently. > However, I think the current state of this is just plain broken-as- > designed. It makes no sense to me to assume that all interfaces are > necessarily available right at boot time, or that any service anywhere > should ever depend on "all datalinks are ready." I think it's the > wrong decomposition of the problem. I don't disagree but having anything more specific than "all (statically configured) datalinks are ready" is a much bigger goal and one even less appropriate to lump into this project. >>network/physical is a misnomer anyway. > > Not really. The distinction is between virtual (i.e., loopback) and > physical (i.e., palpable hardware) interfaces. The word "physical" in > this instance doesn't refer to the OSI model, nor does it really need > to. And the word "network" here doesn't refer to the "network" layer > in OSI, but rather to networking in general, as opposed to (say) file > systems. I certainly agree about the "network" subtree of the FMRI space, it's about networking in general. But it's hard to retrodesign a good basis for the name "physical" (today we use it to configure vni interfaces and some IP tunnels). >>So I guess I have no objection except to leave this reminder that the >>layering violation should eventually be cleaned up by some project. > "Layering violation" ... ? Yes. It should be possible to bring up layer 2 networking without layer 3. And then to choose one of multiple available layer 3 protocols, or one of multiple alternative configurations of layer 3 networking, or no layer 3 networking at all. -=] Mike [=-