From gd78059@sac.sfbay.sun.com Tue Mar 4 21:39:07 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m255d6ZS012273 for ; Tue, 4 Mar 2008 21:39:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m255d3qR028339; Wed, 5 Mar 2008 13:39:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX80080JT13H600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 04 Mar 2008 21:39:03 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX8003TBT12JJ20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 04 Mar 2008 21:39:02 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m255d2U2040305; Tue, 04 Mar 2008 21:39:02 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m255O156011729; Tue, 04 Mar 2008 21:24:01 -0800 (PST) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m255O1eS011725; Tue, 04 Mar 2008 21:24:01 -0800 (PST) Date: Tue, 04 Mar 2008 21:24:01 -0800 (PST) From: "Garrett D'Amore - sun microsystems" Subject: Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] To: PSARC-ext@sun.com Cc: brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Message-id: <200803050524.m255O1eS011725@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5289 I'm sponsoring the following fasttrack for Sowmini Varadhan. Timeout is set for March 11, 2008. Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Brussels: NDD compatiblity support 1.2. Name of Document Author/Supplier: Author: Sowmini Varadhan 1.3 Date of This Document: 04 March, 2008 4. Technical Description Brussels: NDD compatiblity support ---------------------------------- 1. Introduction --------------- This case describes the ``ndd compatibility'' component of the umbrella case for PSARC 2007/429, that will provide legacy support of existing ndd usage at the GLDv3 layer using the methods described in Section 2 of this document. Release binding: minor 2. NDD Compatibility Problem ----------------------------- Drivers typically parse the ioctl data for ndd(1m) ioctls by using undocumented Mentat interfaces like nd_load() and nd_getset() with these calls being unfortunately duplicated across drivers. The duplicated logic can easily be avoided by parsing the ndd ioctl mapping it to GLDv3 calls in the intermediate GLDv3 modules (See CR 6667363). 2.1 Proposed Solution --------------------- Variables typically covered by ndd(1m) for drivers are typically the MII parameters defined in ieee802.3(5). For the purpose of this document, we define these MII parameters, and particularly the syntax used in ieee802.3(5) as "canonical ndd parameters". In addition to the canonical parameters, it is not uncommon to encounter other ndd parameters implemented in many drivers. For example, the bge driver implements "adv_asym_pause_cap" instead of the ieee802.3(5) version, adv_cap_asmpause. This document defines these variant names supported in driver ndd implementations as "non-canonical ndd parameters". The public properties introduced by PSARC 2007/429 ("Brussels Enhanced Network Driver Configuration Via dladm") and the ether_stats introduced by PSARC 2006/248 ("Nemo MAC-Type Plugin Architecture") together cover all of the canonical NDD parameters. Thus, when the mac layer recognizes that mc_setprop and mc_getprop interfaces have been registered for the driver, the ioctl data for the ndd call may be intercepted and parsed at the mac layer and mapped to an equivalent GLDv3 call. All syntax, permission and bound-checks will be performed at the mac layer, and the driver only needs to provide mc_setprop/mc_getprop/mc_getstat callbacks. Non-canonical NDD parameters will be passed to the driver as private properties. The driver would have to do any string processing to parse these properties, but would not need to invoke any other interfaces. such as nd_load(), nd_getset() etc. Note that Drivers not converted to the Brussels framework will continue to function in the pre-Brussels manner. For these drivers, the mac layer will not have a registered mc_setprop or mc_getprop callback, so that the ioctl data will be passed down to the driver without modification. 2.1 Getting Parameters Supported By the Driver ---------------------------------------------- The ndd invocation # ndd -get /dev/ \? has traditionally been used to obtain the list of ndd parameters supported by . Although it is not a Stable interface, this command is widely used so that legacy support is justifiable. Support for this invocation will be provided in the following manner: - The driver must register any non-canonical properties that it supports through its xxattach() routine by invoking the mac_register_priv_prop() interface described in Section 4.1 below. - The mac layer will provide a listing of the canonical ndd names as well as the non-canonical names registed for the driver when it receives a ND_GET ioctl for the "\?" parameter. 4. Exported Interfaces: ----------------------- Interface Classification Comments ----------------------------------------------------------------------------- mac_register_priv_prop Committed Section 4.1 DLD_PERM_{READ, WRITE} Committed r/w permissions for ndd properties defined in DLD_MAP_KSTAT Private used internally to identify ndd props that map to kstats. 4.1 mac_register_priv_prop() ---------------------------- Synopsis: void mac_register_priv_prop(mac_handle_t mh, char *name, int flags) Description: Drivers wishing to support non-canonical ndd parameters must provide the names of these parameters to the GLDv3 framework after succesfully completing mac_register() in their attach(9E) routine. Parameters: mh mac_handle_t obtained after succesfully completing mac_register. name property name of the non-canonical ndd prop to be registered flags property flags defined in which may be a logical OR of {DLD_PERM_READ, DLD_PERM_WRITE}, describing read/write permissions for the property.} Returned value: None. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Sebastien.Roy@sun.com Wed Mar 5 06:49:23 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25EnMgd026549 for ; Wed, 5 Mar 2008 06:49:23 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m25EnGua023130; Wed, 5 Mar 2008 14:49:21 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX900L0LII7R200@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Mar 2008 06:49:19 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX900KA8II4PO10@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Mar 2008 06:49:16 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m25EnGCd018834; Wed, 05 Mar 2008 14:49:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX900B01HQ0HY00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM); Wed, 05 Mar 2008 07:49:16 -0700 (MST) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX900IJCII2X860@mail-amer.sun.com>; Wed, 05 Mar 2008 07:49:15 -0700 (MST) Date: Wed, 05 Mar 2008 09:49:14 -0500 From: Sebastien Roy Subject: Re: Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <200803050524.m255O1eS011725@sac.sfbay.sun.com> Sender: Sebastien.Roy@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Message-id: <47CEB2EA.2020704@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080115) Status: RO Content-Length: 577 Garrett D'Amore - sun microsystems wrote: > > 4. Exported Interfaces: > ----------------------- > > Interface Classification Comments > ----------------------------------------------------------------------------- > mac_register_priv_prop Committed Section 4.1 > DLD_PERM_{READ, WRITE} Committed r/w permissions > for ndd properties > defined in None of GLDv3 is currently Committed, so I find it strange that these additions would be. The driver API portion of GLDv3 is currently Consolidation Private. -Seb From gdamore@opensolaris.org Wed Mar 5 07:08:29 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25F8SAC027398 for ; Wed, 5 Mar 2008 07:08:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m25F8MiR002370 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Mar 2008 15:08:28 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX900K21JE1E200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 05 Mar 2008 08:08:25 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX900D1IJDZPF40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 05 Mar 2008 08:08:24 -0700 (MST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m25F76A9024324 for ; Wed, 05 Mar 2008 15:08:23 +0000 (GMT) Received: from mms23es.sun.com ([150.143.232.54] [150.143.232.54]) by relay22i.sun.com with ESMTP id BT-MMP-818227 for PSARC-ext@Sun.COM; Wed, 05 Mar 2008 15:08:23 +0000 (Z) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54]) by mms23es.sun.com with ESMTP id BT-MMP-2853644 for PSARC-ext@Sun.COM; Wed, 05 Mar 2008 15:08:23 +0000 (Z) Received: from outbound-mail-28.bluehost.com ([69.89.17.198] [69.89.17.198]) by relay23i.sun.com id BT-MMP-17738024 for PSARC-ext@Sun.COM; Wed, 05 Mar 2008 15:08:23 +0000 (Z) Received: (qmail 20448 invoked by uid 0); Wed, 05 Mar 2008 15:06:41 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by outboundproxy2.bluehost.com with SMTP; Wed, 05 Mar 2008 15:06:41 +0000 Received: from sca-ea-fw-1.sun.com ([192.18.43.225] helo=[10.7.251.172]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JWvCb-0005ro-HY; Wed, 05 Mar 2008 08:06:41 -0700 Date: Wed, 05 Mar 2008 07:04:24 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47CEB2EA.2020704@sun.com> To: Sebastien Roy Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Reply-to: gdamore@opensolaris.org Message-id: <47CEB678.7020202@opensolaris.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 192.18.43.225 authed with garrett+damore.org} X-Antispam: No, score=-2.6/5.0, scanned in 0.074sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <47CEB2EA.2020704@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1012 Sebastien Roy wrote: > Garrett D'Amore - sun microsystems wrote: > >> 4. Exported Interfaces: >> ----------------------- >> >> Interface Classification Comments >> ----------------------------------------------------------------------------- >> mac_register_priv_prop Committed Section 4.1 >> DLD_PERM_{READ, WRITE} Committed r/w permissions >> for ndd properties >> defined in >> > > None of GLDv3 is currently Committed, so I find it strange that these > additions would be. The driver API portion of GLDv3 is currently > Consolidation Private. > > -Seb > _______________________________________________ > brussels-dev mailing list > brussels-dev@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/brussels-dev > That is an excellent point, that somehow didn't cross my mind when I was reviewing this prior to submission. I agree, given that Nemo itself isn't public yet, I don't think these should be. -- Garrett From sowmini.varadhan@sun.com Wed Mar 5 07:39:20 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25FdKmb028512 for ; Wed, 5 Mar 2008 07:39:20 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m25FdGMW058765; Wed, 5 Mar 2008 08:39:20 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX900M0SKTJOJ00@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 08:39:19 -0700 (MST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX900DDEKTDP160@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 08:39:13 -0700 (MST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m25FdCfX032860; Wed, 05 Mar 2008 10:39:12 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m25FFsRm011101; Wed, 05 Mar 2008 10:15:54 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m25FFs8p011100; Wed, 05 Mar 2008 10:15:54 -0500 (EST) Date: Wed, 05 Mar 2008 10:15:54 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47CEB678.7020202@opensolaris.org> To: "Garrett D'Amore" Cc: Sebastien Roy , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Message-id: <20080305151554.GO4142@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <47CEB2EA.2020704@sun.com> <47CEB678.7020202@opensolaris.org> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 272 On (03/05/08 07:04), Garrett D'Amore wrote: > > That is an excellent point, that somehow didn't cross my mind when I was > reviewing this prior to submission. I agree, given that Nemo itself > isn't public yet, I don't think these should be. > Accepted. --Sowmini From peter.memishian@sun.com Wed Mar 5 19:10:19 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m263AIjG000127 for ; Wed, 5 Mar 2008 19:10:18 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m263AEqr015978; Thu, 6 Mar 2008 03:10:17 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00603GT38000@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Mar 2008 19:10:15 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA005KVGT2QT00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Mar 2008 19:10:15 -0800 (PST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m263ACaJ034053; Wed, 05 Mar 2008 22:10:12 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m263AC0d136625; Wed, 05 Mar 2008 22:10:12 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m263ACKI136563; Wed, 05 Mar 2008 22:10:12 -0500 (EST) Date: Wed, 05 Mar 2008 22:10:11 -0500 From: Peter Memishian Subject: re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <200803050524.m255O1eS011725@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Reply-to: peter.memishian@sun.com Message-id: <18383.24723.868952.124862@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1698 A few minor comment on some details: > Interface Classification Comments > ----------------------------------------------------------------------------- > mac_register_priv_prop Committed Section 4.1 > DLD_PERM_{READ, WRITE} Committed r/w permissions > for ndd properties > defined in I'm surprised to see the DLD namespace (and the header) leaking into the MAC driver API. The DLD prefix is intended to be used by the private API between libdladm and the data link driver (dld) itself. It's not clear to me what that has to do the MAC driver API exported to drivers. (I see that the existing Brussels link properties use "DLD" too, but I don't understand that either. I also see there appear to be unused DLD_NDD_{READ,WRITE} #defines adrift in Nevada.) > Synopsis: > void mac_register_priv_prop(mac_handle_t mh, char *name, int flags) Seems like `name' should be `const char *' and `flags' should be unsigned. > Description: > > Drivers wishing to support non-canonical ndd parameters must provide > the names of these parameters to the GLDv3 framework after > succesfully completing mac_register() in their attach(9E) routine. > > > Parameters: > mh mac_handle_t obtained after succesfully completing mac_register. > name property name of the non-canonical ndd prop to be registered What happens if the name passed in is already a canonical ndd property? Is it just silently ignored? > flags property flags defined in which may be a logical OR of > {DLD_PERM_READ, DLD_PERM_WRITE}, describing read/write permissions > for the property.} -- meem From gdamore@sun.com Wed Mar 5 20:28:34 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m264SYO5002308 for ; Wed, 5 Mar 2008 20:28:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m264SYY7022682; Wed, 5 Mar 2008 20:28:34 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00C01KFMYE00@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 21:28:34 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA00AJMKFLEM10@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 21:28:33 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m264SXh9004311; Wed, 05 Mar 2008 20:28:33 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXA00401KCFGH00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 05 Mar 2008 20:28:33 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXA002YNKFK6BA0@fe-sfbay-09.sun.com>; Wed, 05 Mar 2008 20:28:32 -0800 (PST) Date: Wed, 05 Mar 2008 20:26:19 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18383.24723.868952.124862@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: Peter.Memishian@sun.com Cc: "Garrett D'Amore - sun microsystems" , psarc-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Message-id: <47CF726B.6070300@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2302 Peter Memishian wrote: > A few minor comment on some details: > > > Interface Classification Comments > > ----------------------------------------------------------------------------- > > mac_register_priv_prop Committed Section 4.1 > > DLD_PERM_{READ, WRITE} Committed r/w permissions > > for ndd properties > > defined in > > I'm surprised to see the DLD namespace (and the header) > leaking into the MAC driver API. The DLD prefix is intended to be used by > the private API between libdladm and the data link driver (dld) itself. > It's not clear to me what that has to do the MAC driver API exported to > drivers. (I see that the existing Brussels link properties use "DLD" too, > but I don't understand that either. I also see there appear to be unused > DLD_NDD_{READ,WRITE} #defines adrift in Nevada.) > I've always felt the distinction between dld and mac "felt" random at times. Add in dls, and mere mortals like myself have a really hard time figuring out what lives where. I would be happier to see consistent naming in the APIs though, admittedly. Perhaps this can be rectified with a follow-on fast-track for Brussels. (Things like this are one of the reasons that I've been hesitant in the past to raise commitment levels of Nemo related APIs too quickly, btw.) > > Synopsis: > > void mac_register_priv_prop(mac_handle_t mh, char *name, int flags) > > Seems like `name' should be `const char *' and `flags' should be unsigned. > Concur. > > Description: > > > > Drivers wishing to support non-canonical ndd parameters must provide > > the names of these parameters to the GLDv3 framework after > > succesfully completing mac_register() in their attach(9E) routine. > > > > > > Parameters: > > mh mac_handle_t obtained after succesfully completing mac_register. > > name property name of the non-canonical ndd prop to be registered > > What happens if the name passed in is already a canonical ndd property? > Is it just silently ignored? > Good question. Programmer error is my first thought -- at one point we had the idea that "private" names were supposed to start with a "_" or somesuch. Maybe the results are "undefined"? Sowmini? -- Garrett From peter.memishian@sun.com Wed Mar 5 20:39:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m264duHd002370 for ; Wed, 5 Mar 2008 20:39:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m264dqpp014332; Thu, 6 Mar 2008 12:39:54 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00B0JKYF4R00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Mar 2008 20:39:51 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA009ASKYEK000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Mar 2008 20:39:50 -0800 (PST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m264dmsA043679; Wed, 05 Mar 2008 23:39:48 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m264dma4979074; Wed, 05 Mar 2008 23:39:48 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m264dmHp979071; Wed, 05 Mar 2008 23:39:48 -0500 (EST) Date: Wed, 05 Mar 2008 23:39:48 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47CF726B.6070300@sun.com> To: "Garrett D'Amore" Cc: peter.memishian@sun.com, "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Reply-to: peter.memishian@sun.com Message-id: <18383.30100.23372.314937@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <47CF726B.6070300@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1597 > > I'm surprised to see the DLD namespace (and the header) > > leaking into the MAC driver API. The DLD prefix is intended to be used by > > the private API between libdladm and the data link driver (dld) itself. > > It's not clear to me what that has to do the MAC driver API exported to > > drivers. (I see that the existing Brussels link properties use "DLD" too, > > but I don't understand that either. I also see there appear to be unused > > DLD_NDD_{READ,WRITE} #defines adrift in Nevada.) > > I've always felt the distinction between dld and mac "felt" random at > times. For the MAC Client API it can be a bit blurry, but the MAC Driver API seems clearer. I looked a number of GLDv3 drivers in ON using the API and none of them (aside from bge with the Brussels conversion) are pulling in . My understanding is that is an implementation detail, and does not belong in any APIs that we might raise to committed. > Add in dls, and mere mortals like myself have a really hard time > figuring out what lives where. I hear that a lot of this is changing with Crossbow, so hopefully it will be getting simpler. > I would be happier to see consistent naming in the APIs though, > admittedly. Perhaps this can be rectified with a follow-on fast-track > for Brussels. (Things like this are one of the reasons that I've been > hesitant in the past to raise commitment levels of Nemo related APIs too > quickly, btw.) Why not fix this now? (The existing Brussels DLD_* constants can be dealt with at another time.) -- meem From gdamore@sun.com Wed Mar 5 20:55:18 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m264tHhp002716 for ; Wed, 5 Mar 2008 20:55:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m264tCUn019506; Thu, 6 Mar 2008 12:55:16 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00F05LO37000@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 21:55:16 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA00ASTLO3ER20@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 21:55:15 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m264tFPJ005195; Wed, 05 Mar 2008 20:55:15 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXA00F01LKIQ800@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 05 Mar 2008 20:55:15 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXA002MYLO26BF0@fe-sfbay-09.sun.com>; Wed, 05 Mar 2008 20:55:15 -0800 (PST) Date: Wed, 05 Mar 2008 20:53:01 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18383.30100.23372.314937@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: Peter.Memishian@sun.com Cc: "Garrett D'Amore - sun microsystems" , psarc-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Message-id: <47CF78AD.8080903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <47CF726B.6070300@sun.com> <18383.30100.23372.314937@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2188 Peter Memishian wrote: > > > I'm surprised to see the DLD namespace (and the header) > > > leaking into the MAC driver API. The DLD prefix is intended to be used by > > > the private API between libdladm and the data link driver (dld) itself. > > > It's not clear to me what that has to do the MAC driver API exported to > > > drivers. (I see that the existing Brussels link properties use "DLD" too, > > > but I don't understand that either. I also see there appear to be unused > > > DLD_NDD_{READ,WRITE} #defines adrift in Nevada.) > > > > I've always felt the distinction between dld and mac "felt" random at > > times. > > For the MAC Client API it can be a bit blurry, but the MAC Driver API > seems clearer. I looked a number of GLDv3 drivers in ON using the API and > none of them (aside from bge with the Brussels conversion) are pulling in > . My understanding is that is an implementation > detail, and does not belong in any APIs that we might raise to committed. > Okay, well this is a good point to raise. I wish it had been raised back when we were reviewing PSARC 2007/429. Oh well, I'm as guilty of anyone. ;-) Meanwhile, at least nothing here is public, so its not too late fix it now. > > Add in dls, and mere mortals like myself have a really hard time > > figuring out what lives where. > > I hear that a lot of this is changing with Crossbow, so hopefully it will > be getting simpler. > Good. I seem to recall hearing about plans to merge dls and dld, but I don't recall exactly the details. > > I would be happier to see consistent naming in the APIs though, > > admittedly. Perhaps this can be rectified with a follow-on fast-track > > for Brussels. (Things like this are one of the reasons that I've been > > hesitant in the past to raise commitment levels of Nemo related APIs too > > quickly, btw.) > > Why not fix this now? (The existing Brussels DLD_* constants can be dealt > with at another time.) > For this case, I'll leave that decision up to the project team. (Clearly the existing Brussels API will need to be changed at some point as well.) - Garrett From peter.memishian@sun.com Wed Mar 5 21:07:58 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2657vTf002836 for ; Wed, 5 Mar 2008 21:07:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2657lJu024245; Thu, 6 Mar 2008 13:07:55 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00G05M936Y00@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 22:07:51 -0700 (MST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA00AOHM92EO30@brm-avmta-1.central.sun.com>; Wed, 05 Mar 2008 22:07:51 -0700 (MST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2657m1t058484; Thu, 06 Mar 2008 00:07:48 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2657mn4227957; Thu, 06 Mar 2008 00:07:48 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2657m2l227944; Thu, 06 Mar 2008 00:07:48 -0500 (EST) Date: Thu, 06 Mar 2008 00:07:48 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47CF78AD.8080903@sun.com> To: "Garrett D'Amore" Cc: peter.memishian@sun.com, "Garrett D'Amore - sun microsystems" , psarc-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Reply-to: peter.memishian@sun.com Message-id: <18383.31780.603251.127224@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <47CF726B.6070300@sun.com> <18383.30100.23372.314937@gargle.gargle.HOWL> <47CF78AD.8080903@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 262 > Okay, well this is a good point to raise. I wish it had been raised > back when we were reviewing PSARC 2007/429. Oh well, I'm as guilty of > anyone. ;-) Meanwhile, at least nothing here is public, so its not too > late fix it now. Yep. -- meem From sowmini.varadhan@sun.com Thu Mar 6 03:40:23 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26BeMqg012524 for ; Thu, 6 Mar 2008 03:40:23 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26BeLYp023305; Thu, 6 Mar 2008 11:40:21 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0011R4F8G800@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 04:40:20 -0700 (MST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00C824F7GKB0@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 04:40:20 -0700 (MST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26BeJbZ012067; Thu, 06 Mar 2008 06:40:19 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26BOV1o011767; Thu, 06 Mar 2008 06:24:31 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26BOVwP011766; Thu, 06 Mar 2008 06:24:31 -0500 (EST) Date: Thu, 06 Mar 2008 06:24:31 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18383.24723.868952.124862@gargle.gargle.HOWL> To: Peter Memishian Cc: "Garrett D'Amore - sun microsystems" , psarc-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Message-id: <20080306112431.GD11550@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 1476 On (03/05/08 22:10), Peter Memishian wrote: > > I'm surprised to see the DLD namespace (and the header) > leaking into the MAC driver API. The DLD prefix is intended to be > used by > the private API between libdladm and the data link driver (dld) > itself. > It's not clear to me what that has to do the MAC driver API exported > to > drivers. (I see that the existing Brussels link properties use "DLD" > too, > but I don't understand that either. I also see there appear to be > unused > DLD_NDD_{READ,WRITE} #defines adrift in Nevada.) There is a lager issue here: should user space apps that issue the DLDIOC*PROP ioctls need mac.h to get the property numbers, or should drivers include dld.h? As you point out, this debate was not entered into for 2007/429, and the choice made there was that DLDIOC*PROP ioctls would have DLD-prefixed property numbers, all of which would be in dld.h. Changing that convention is not the subject of this proposal, and would be better examined in its own case. For this particular case, since these flags are strictly between the mac layer and the gld layer, we can rename them to MAC_PERM*. > > Parameters: > > mh mac_handle_t obtained after succesfully completing > > mac_register. > > name property name of the non-canonical ndd prop to be > > registered > > What happens if the name passed in is already a canonical ndd > property? > Is it just silently ignored? It would be ignored. --Sowmini From sowmini.varadhan@sun.com Thu Mar 6 03:55:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26BtlJx012867 for ; Thu, 6 Mar 2008 03:55:48 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26BtiG4028918; Thu, 6 Mar 2008 11:55:45 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0070D54ULF00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 03:55:42 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB0056054U0J60@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 03:55:42 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26BtfiY015435; Thu, 06 Mar 2008 06:55:41 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26BdrLg011804; Thu, 06 Mar 2008 06:39:53 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26BdrmP011803; Thu, 06 Mar 2008 06:39:53 -0500 (EST) Date: Thu, 06 Mar 2008 06:39:53 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47CF78AD.8080903@sun.com> To: "Garrett D'Amore" Cc: Peter.Memishian@sun.com, "Garrett D'Amore - sun microsystems" , psarc-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com Message-id: <20080306113953.GE11550@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <47CF726B.6070300@sun.com> <18383.30100.23372.314937@gargle.gargle.HOWL> <47CF78AD.8080903@sun.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 1092 On (03/05/08 20:53), Garrett D'Amore wrote: >> > I would be happier to see consistent naming in the APIs though, > >> admittedly. Perhaps this can be rectified with a follow-on >> fast-track >> > for Brussels. (Things like this are one of the reasons that I've >> been > hesitant in the past to raise commitment levels of Nemo >> related >> APIs too > quickly, btw.) >> >> Why not fix this now? (The existing Brussels DLD_* constants can be >> dealt >> with at another time.) >> > > For this case, I'll leave that decision up to the project team. > (Clearly the existing Brussels API will need to be changed at some > point > as well.) > I'm a little lost in the replies that were going around last night. What exactly do we want to fix? As I said earlier, the convention right now is that the DLD*PROP ioctls have prop numbers prefixed with "DLD". Both libdladm and the drivers need access to the property numbers, and libdladm issues the DLD*ioctl. Piling a re-org of all this in the "ndd compat" case runs the risk of worsening any incongruities that exist. --Sowmini From peter.memishian@sun.com Thu Mar 6 10:36:29 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26IaSGj028114 for ; Thu, 6 Mar 2008 10:36:28 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26IaQu5012200; Thu, 6 Mar 2008 10:36:28 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0000HNOR6V00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 10:36:27 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00I9CNOQV6B0@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 10:36:27 -0800 (PST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26IaOBY013545; Thu, 06 Mar 2008 13:36:24 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26IaOY4093830; Thu, 06 Mar 2008 13:36:24 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m26IaO2K093817; Thu, 06 Mar 2008 13:36:24 -0500 (EST) Date: Thu, 06 Mar 2008 13:36:23 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080306112431.GD11550@quasimodo.East.Sun.COM> To: Sowmini.Varadhan@sun.com Cc: Peter Memishian , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" , sowmini-varadhan@sun.com Reply-to: peter.memishian@sun.com Message-id: <18384.14759.999824.809885@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1042 > There is a lager issue here: should user space apps that issue the > DLDIOC*PROP ioctls need mac.h to get the property numbers, or > should drivers include dld.h? I don't see an issue with user-space making use of -- it'll ultimately be a public part of the GLDv3 API. On the other hand, having e.g. third-party GLDv3 drivers pulling in an implementation detail like is a problem. (Note that user-space apps are otherwise insulated from the DLD namespace since e.g. DLDIOC*PROP is actually issued by libdladm on behalf of userland.) > > What happens if the name passed in is already a canonical ndd > > property? Is it just silently ignored? > > It would be ignored. I presume the same would be true if it attempted to register a framework link property name like "autopush"? If so, that seems dangerous since namespace collisions that may be introduced over time (e.g., as we grow the set of framework-native link properties) will go unreported, which may lead to unpredictable behavior. -- meem From gdamore@sun.com Thu Mar 6 10:48:00 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26Im0b8028458 for ; Thu, 6 Mar 2008 10:48:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26Ilxin051836; Thu, 6 Mar 2008 11:48:00 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0040TO7ZTF00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 10:47:59 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00LINO7YH9D0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 10:47:58 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26IlwS0021697; Thu, 06 Mar 2008 10:47:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00A01NO9YU00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Thu, 06 Mar 2008 10:47:58 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB00AR3O7PY760@fe-sfbay-09.sun.com>; Thu, 06 Mar 2008 10:47:49 -0800 (PST) Date: Thu, 06 Mar 2008 10:45:34 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.14759.999824.809885@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: Peter.Memishian@sun.com Cc: Sowmini.Varadhan@sun.com, psarc-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" , sowmini-varadhan@sun.com Message-id: <47D03BCE.90204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2118 Peter Memishian wrote: > > There is a lager issue here: should user space apps that issue the > > DLDIOC*PROP ioctls need mac.h to get the property numbers, or > > should drivers include dld.h? > > I don't see an issue with user-space making use of -- it'll > ultimately be a public part of the GLDv3 API. On the other hand, having > e.g. third-party GLDv3 drivers pulling in an implementation detail like > is a problem. (Note that user-space apps are otherwise > insulated from the DLD namespace since e.g. DLDIOC*PROP is actually issued > by libdladm on behalf of userland.) > I tend to agree. If its desirable for consistency, one can do something later like: #define DLD_PROP_PERM_READ MAC_PROP_PERM_READ This allows for keeping the names at least a little more consistent in consuming code. > > > What happens if the name passed in is already a canonical ndd > > > property? Is it just silently ignored? > > > > It would be ignored. > > I presume the same would be true if it attempted to register a framework > link property name like "autopush"? If so, that seems dangerous since > namespace collisions that may be introduced over time (e.g., as we grow > the set of framework-native link properties) will go unreported, which may > lead to unpredictable behavior. > This is a general risk with private properties. We should be pressing *really* hard for the complete eradication of unqualified private property names, and frankly also pressing pretty hard for drivers to avoid use of "synonyms" and such, but instead use official public properties where possible. But, along these lines, I did have the thought (which won't really help for ndd) that dladm could have a different flag/option to access private properties. Sort of like cfgadm's -x option for "hardware-specific" operations, and -c for standard operations. This also would help underscore to the user/admin that the property names are not necessarily portable across drivers, and it would avoid the namespace collision problem (at least at the dladm level.) -- Garrett From sowmini.varadhan@sun.com Thu Mar 6 11:15:11 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JFB29029522 for ; Thu, 6 Mar 2008 11:15:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JF9jR022354 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Mar 2008 19:15:10 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00111PH8PG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 11:15:08 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00IMAPH6UQC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 11:15:07 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JF66w012356; Thu, 06 Mar 2008 14:15:06 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26IxH35013503; Thu, 06 Mar 2008 13:59:17 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26IxHlD013502; Thu, 06 Mar 2008 13:59:17 -0500 (EST) Date: Thu, 06 Mar 2008 13:59:17 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.14759.999824.809885@gargle.gargle.HOWL> To: Peter Memishian Cc: PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <20080306185917.GH4142@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 2370 On (03/06/08 13:36), Peter Memishian wrote: > > There is a lager issue here: should user space apps that issue the > > DLDIOC*PROP ioctls need mac.h to get the property numbers, or > > should drivers include dld.h? > > I don't see an issue with user-space making use of -- it'll > ultimately be a public part of the GLDv3 API. On the other hand, having > e.g. third-party GLDv3 drivers pulling in an implementation detail like > is a problem. (Note that user-space apps are otherwise > insulated from the DLD namespace since e.g. DLDIOC*PROP is actually issued > by libdladm on behalf of userland.) I still feel that this merits its own case: the ioctl itself could, in theory, be issued by any app. Moreover, the naming convention here is not clear to me: will DLD*PROP ioctls pass down a dld_ioc_prop_t structure that has pr_num that starts with "MAC"? In this model, will dld_ioc_prop_t structures live in dld.h, and the MAC* definitions in mac.h? There's a lot of parameters here, and I am not comfortable mixing those parameters into this case. We could address the naming conventions for the DLD*prop in a separate case. Is that acceptable? > > > > What happens if the name passed in is already a canonical ndd > > > property? Is it just silently ignored? > > > > It would be ignored. > > I presume the same would be true if it attempted to register a framework > link property name like "autopush"? If so, that seems dangerous since > namespace collisions that may be introduced over time (e.g., as we grow This is not intended to be a general purpose mechanism for property management at all, and is really only intended for the "legacy" ndd props. /sbin/dladm itself will filter out private properties that do not begin with "_". In the example that you cite, if "autopush" is registered, then the (driver-private) implementation would never be accessible via dladm becuase (1) it does not start with "_" (2) the defined precedence is for the public property. > the set of framework-native link properties) will go unreported, which may > lead to unpredictable behavior. If the concern is around the lack of error reporting, the synopsis of mac_register_priv_prop can be changed to return an int, with 0 return status indicating success, and EEXIST indicating that the registered name is a duplicate. --Sowmini From sowmini.varadhan@sun.com Thu Mar 6 11:23:09 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JN9Lr029629 for ; Thu, 6 Mar 2008 11:23:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26JN7Yu064530; Thu, 6 Mar 2008 12:23:08 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00209PUJ2300@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 11:23:07 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00I8QPUIUQD0@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 11:23:06 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JN5QQ015333; Thu, 06 Mar 2008 14:23:05 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26J7GZq013521; Thu, 06 Mar 2008 14:07:16 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26J7Gra013520; Thu, 06 Mar 2008 14:07:16 -0500 (EST) Date: Thu, 06 Mar 2008 14:07:16 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47D03BCE.90204@sun.com> To: "Garrett D'Amore" Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <20080306190716.GJ4142@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <47D03BCE.90204@sun.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 760 On (03/06/08 10:45), Garrett D'Amore wrote: > > #define DLD_PROP_PERM_READ MAC_PROP_PERM_READ > > This allows for keeping the names at least a little more consistent in > consuming code. For this particular case (permissions passed between GLDv3 <-> driver for mac_register_priv_prop()) the issues are simplified, because we are only talking about interfaces between the driver and GLDv3 itself. I think I had mentioned already: s/DLD_PERM/MAC_PERM s/DLD_MAP/MAC_MAP MAC_PERM_* constants and MAC_MAP* constants will reside in The larger question of where the information related to the DLD*PROP ioctls will reside, and how they shall be named (none of which are changed by this case) shall be dealt with in a separate case. --Sowmini From peter.memishian@sun.com Thu Mar 6 11:25:11 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JPA4P029650 for ; Thu, 6 Mar 2008 11:25:11 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26JP8gh026709 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 7 Mar 2008 03:25:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0080LPXV7G00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 11:25:07 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB005V3PXRYMC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 11:25:04 -0800 (PST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JP1nw029975; Thu, 06 Mar 2008 14:25:01 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26JP1oe590158; Thu, 06 Mar 2008 14:25:01 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m26JP1M0590149; Thu, 06 Mar 2008 14:25:01 -0500 (EST) Date: Thu, 06 Mar 2008 14:25:00 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080306185917.GH4142@quasimodo.East.Sun.COM> To: Sowmini.Varadhan@sun.com Cc: Peter Memishian , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Reply-to: peter.memishian@sun.com Message-id: <18384.17676.991107.330710@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 2362 > I still feel that this merits its own case: the ioctl itself could, > in theory, be issued by any app. How so? The DLD ioctl API will never be public. We may (on the other hand) commit the libdladm API. > Moreover, the naming convention here is not clear to me: will DLD*PROP > ioctls pass down a dld_ioc_prop_t structure that has pr_num that starts > with "MAC"? In this model, will dld_ioc_prop_t structures live in > dld.h, and the MAC* definitions in mac.h? There's a lot of parameters > here, and I am not comfortable mixing those parameters into this > case. We could address the naming conventions for the DLD*prop in a > separate case. Is that acceptable? It's acceptable to me, but I'm just a PSARC licensee, so what I think doesn't really matter ;-) > > I presume the same would be true if it attempted to register a framework > > link property name like "autopush"? If so, that seems dangerous since > > namespace collisions that may be introduced over time (e.g., as we grow > > This is not intended to be a general purpose mechanism for property > management at all, and is really only intended for the "legacy" ndd > props. Hmm, I think I'm thrown off by the name; "mac_register_priv_prop()" seems to be generic to all driver-private properties. > /sbin/dladm itself will filter out private properties that do not begin > with "_". In the example that you cite, if "autopush" is registered, > then the (driver-private) implementation would never be accessible via > dladm becuase (1) it does not start with "_" (2) the defined precedence > is for the public property. Now I'm confused. I thought the goal was backward-compatibility with any existing non-canonical ndd parameters, but I don't quite see how that compatibility is provided given the "_" constraint above. Is there a mapping going on that isn't described in the original proposal? > > the set of framework-native link properties) will go unreported, which may > > lead to unpredictable behavior. > > If the concern is around the lack of error reporting, the synopsis > of mac_register_priv_prop can be changed to return an int, with 0 > return status indicating success, and EEXIST indicating that the > registered name is a duplicate. That is one of the concerns, but I'm really trying to sleuth out the various edge cases. -- meem From gdamore@sun.com Thu Mar 6 11:29:11 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JTAWc029766 for ; Thu, 6 Mar 2008 11:29:11 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26JT3RN028170 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 7 Mar 2008 03:29:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0081PQ4KHQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 06 Mar 2008 11:29:08 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00503Q4IYMF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 06 Mar 2008 11:29:06 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26JT6La028020 for ; Thu, 06 Mar 2008 11:29:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00301ORJEO00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 06 Mar 2008 11:29:06 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB00GEEQ3ZFOC0@fe-sfbay-09.sun.com>; Thu, 06 Mar 2008 11:28:55 -0800 (PST) Date: Thu, 06 Mar 2008 11:26:32 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080306185917.GH4142@quasimodo.East.Sun.COM> Sender: Garrett.Damore@sun.com To: Sowmini.Varadhan@sun.com Cc: Peter Memishian , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <47D04568.4030003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2967 Sowmini.Varadhan@Sun.COM wrote: > On (03/06/08 13:36), Peter Memishian wrote: > >> > There is a lager issue here: should user space apps that issue the >> > DLDIOC*PROP ioctls need mac.h to get the property numbers, or >> > should drivers include dld.h? >> >> I don't see an issue with user-space making use of -- it'll >> ultimately be a public part of the GLDv3 API. On the other hand, having >> e.g. third-party GLDv3 drivers pulling in an implementation detail like >> is a problem. (Note that user-space apps are otherwise >> insulated from the DLD namespace since e.g. DLDIOC*PROP is actually issued >> by libdladm on behalf of userland.) >> > > I still feel that this merits its own case: the ioctl itself could, > in theory, be issued by any app. Moreover, the naming convention here > is not clear to me: will DLD*PROP ioctls pass down a dld_ioc_prop_t > structure that has pr_num that starts with "MAC"? In this model, > will dld_ioc_prop_t structures live in dld.h, and the MAC* definitions > in mac.h? There's a lot of parameters here, and I am not comfortable > mixing those parameters into this case. We could address the > naming conventions for the DLD*prop in a separate case. Is that > acceptable? > It is to me. Meem? > >> > > What happens if the name passed in is already a canonical ndd >> > > property? Is it just silently ignored? >> > >> > It would be ignored. >> >> I presume the same would be true if it attempted to register a framework >> link property name like "autopush"? If so, that seems dangerous since >> namespace collisions that may be introduced over time (e.g., as we grow >> > > This is not intended to be a general purpose mechanism for property > management at all, and is really only intended for the "legacy" ndd > props. /sbin/dladm itself will filter out private properties that > do not begin with "_". In the example that you cite, if "autopush" is > registered, then the (driver-private) implementation would never be > accessible via dladm becuase (1) it does not start with "_" (2) the > defined precedence is for the public property. > Thanks for the clarification regarding the "_" prefix. > >> the set of framework-native link properties) will go unreported, which may >> lead to unpredictable behavior. >> > > If the concern is around the lack of error reporting, the synopsis > of mac_register_priv_prop can be changed to return an int, with 0 > return status indicating success, and EEXIST indicating that the > registered name is a duplicate. > Probably not of much value, IMO. (We need to be trying to wean developers off of private properties and ndd, and if I can avoid having to have error checks in the driver, it will make for shorter/cleaner/simpler code in the driver -- that's a good thing IMO.) I'd like to ensure that the "names" passed to mac_register_priv_prop also start with an underscore. -- Garrett From Peter.Memishian@sun.com Thu Mar 6 11:31:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JV6xo029830 for ; Thu, 6 Mar 2008 11:31:06 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26JUvVZ001801; Thu, 6 Mar 2008 12:31:05 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0020JQ7RC200@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 11:31:03 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00I3KQ7OUQE0@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 11:31:00 -0800 (PST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JUvaX017886; Thu, 06 Mar 2008 14:30:57 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26JUoro631494; Thu, 06 Mar 2008 14:30:57 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m26IdWpj127127; Thu, 06 Mar 2008 13:39:32 -0500 (EST) Date: Thu, 06 Mar 2008 13:39:32 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080306113953.GE11550@quasimodo.East.Sun.COM> To: sowmini.varadhan@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, sowmini-varadhan@sun.com, "Garrett D'Amore - sun microsystems" , Peter.Memishian@sun.com Reply-to: Peter.Memishian@sun.com Message-id: <18384.14948.493152.993399@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <47CF726B.6070300@sun.com> <18383.30100.23372.314937@gargle.gargle.HOWL> <47CF78AD.8080903@sun.com> <20080306113953.GE11550@quasimodo.East.Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 266 > I'm a little lost in the replies that were going around > last night. What exactly do we want to fix? Nothing outside of the GLDv3 framework and libdladm should know about DLD, or we risk sedimenting internal architecture that we may want to change. -- meem From sowmini.varadhan@sun.com Thu Mar 6 11:56:33 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JuXoT001184 for ; Thu, 6 Mar 2008 11:56:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26JuV2Q004871 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Mar 2008 11:56:33 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00F0XRE8E700@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Mar 2008 12:56:32 -0700 (MST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB003OFRE6PQ90@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Mar 2008 12:56:31 -0700 (MST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JuU0e025767; Thu, 06 Mar 2008 14:56:30 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26JefgU013538; Thu, 06 Mar 2008 14:40:41 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26JefCK013537; Thu, 06 Mar 2008 14:40:41 -0500 (EST) Date: Thu, 06 Mar 2008 14:40:41 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.17676.991107.330710@gargle.gargle.HOWL> To: Peter Memishian Cc: psarc-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <20080306194041.GK4142@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <18384.17676.991107.330710@gargle.gargle.HOWL> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 4278 On (03/06/08 14:25), Peter Memishian wrote: > > Moreover, the naming convention here is not clear to me: will DLD*PROP > > ioctls pass down a dld_ioc_prop_t structure that has pr_num that starts > > with "MAC"? In this model, will dld_ioc_prop_t structures live in > > dld.h, and the MAC* definitions in mac.h? There's a lot of parameters > > here, and I am not comfortable mixing those parameters into this > > case. We could address the naming conventions for the DLD*prop in a > > separate case. Is that acceptable? > > It's acceptable to me, but I'm just a PSARC licensee, so what I think > doesn't really matter ;-) Would PSARC like to see this coalesced into this case? One of the points raised by Garrett, when I initially combined PSARC 2008/171 and 2008/175 into one case, is that it's better to keep them separate so that the mail threads discussing the issues can be kept sepaarte. > > This is not intended to be a general purpose mechanism for property > > management at all, and is really only intended for the "legacy" ndd > > props. > > Hmm, I think I'm thrown off by the name; "mac_register_priv_prop()" seems > to be generic to all driver-private properties. I initially called it "mac_register_ndd_prop", but Garrett suggested the latter name. I'm not particularly attached to one or the other. > > > /sbin/dladm itself will filter out private properties that do not begin > > with "_". In the example that you cite, if "autopush" is registered, > > then the (driver-private) implementation would never be accessible via > > dladm becuase (1) it does not start with "_" (2) the defined precedence > > is for the public property. > > Now I'm confused. I thought the goal was backward-compatibility with any > existing non-canonical ndd parameters, but I don't quite see how that > compatibility is provided given the "_" constraint above. Is there a > mapping going on that isn't described in the original proposal? The non-canonical ndd props are usually variants like "adv_asym_pause_cap" instead of "adv_asympause_cap" etc. In this particular case (adv_asympause_cap) Brussels provides the cleaner implementation of the flowctrl property. Thus the non-canonical-ndd-param support is only in place for user apps and scripts that have commands (or equivalent c code) that does "ndd {-set, -get} /dev/ adv_asym_pause_cap <..>". We *could* enforce the private prop implementation of these in drivers to prefix the name ("adv_asym_pause_cap") with a "_" ("_adv_asym_pause_cap") and add the "_" prefix when translating the ndd call into a private prop call in GLDv3, but, while this allows the property to be accessed via dladm, it creates more confusion in the driver implementation (use "ndd -set .. adv_asym_pause_cap", or "dladm set-linkprop -p _adv_asym_pause_cap"). It's not even clear to me that we need to support many of these non-canonical props via dladm (there's no "backward" compat issue here, unlike ndd). FWIW, I spelled out the alternatives are laid out in http://mail.opensolaris.org/pipermail/brussels-dev/2008-February/000709.html 1.1 make the driver implement the non-canonical property as "_link_tx_pause" and have mac_ndd.c prefix the "_" when calling the driver 1.2 go with my prototype, which would make the non-canonical props inaccessible from dladm. Note that /sbin/dladm filters out properties that don't start with "_" I see no clear advantage in either of these 2 choices. Morever, as we convert each driver, we are cleaning up most of the non-canonical props, so I made the simpler choice of 1.2. Note that, esp after PSARC 2008/175, the dladm private prop mech has an edge over ndd because of the persistent settings provided and access to default values > > > the set of framework-native link properties) will go unreported, which may > > > lead to unpredictable behavior. > > > > If the concern is around the lack of error reporting, the synopsis > > of mac_register_priv_prop can be changed to return an int, with 0 > > return status indicating success, and EEXIST indicating that the > > registered name is a duplicate. > > That is one of the concerns, but I'm really trying to sleuth out the > various edge cases. Ok. --Sowmini From sowmini.varadhan@sun.com Thu Mar 6 12:02:37 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26K2aiU001471 for ; Thu, 6 Mar 2008 12:02:36 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26K2NNe011887; Fri, 7 Mar 2008 04:02:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00B01RO8UA00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 12:02:32 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00B78RO7NB00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 12:02:32 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26K2Ve6027771; Thu, 06 Mar 2008 15:02:31 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26JkgxD013551; Thu, 06 Mar 2008 14:46:42 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26JkgVH013550; Thu, 06 Mar 2008 14:46:42 -0500 (EST) Date: Thu, 06 Mar 2008 14:46:42 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47D04568.4030003@sun.com> To: "Garrett D'Amore" Cc: Peter Memishian , psarc-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <20080306194642.GL4142@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 858 On (03/06/08 11:26), Garrett D'Amore wrote: >> If the concern is around the lack of error reporting, the synopsis >> of mac_register_priv_prop can be changed to return an int, with 0 >> return status indicating success, and EEXIST indicating that the >> registered name is a duplicate. > > Probably not of much value, IMO. (We need to be trying to wean > developers off of private properties and ndd, and if I can avoid having > to have error checks in the driver, it will make for > shorter/cleaner/simpler code in the driver -- that's a good thing IMO.) I could not agree more. > I'd like to ensure that the "names" passed to mac_register_priv_prop > also start with an underscore. And have mac_ndd shim strip out (or add in) the "_" prefix to retain compatibility with existing snv output (or input) for the same command? --Sowmini From gdamore@sun.com Thu Mar 6 13:02:43 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26L2gqa006097 for ; Thu, 6 Mar 2008 13:02:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26L2f2w007983 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Mar 2008 21:02:41 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00H03UGGT900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 13:02:40 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00BLZUGGMY70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 13:02:40 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26L2ef1009293 for ; Thu, 06 Mar 2008 13:02:40 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00N01U581L00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 13:02:40 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB00M90UGEVDC0@fe-sfbay-09.sun.com>; Thu, 06 Mar 2008 13:02:39 -0800 (PST) Date: Thu, 06 Mar 2008 13:00:10 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080306194642.GL4142@quasimodo.East.Sun.COM> Sender: Garrett.Damore@sun.com To: Sowmini.Varadhan@sun.com Cc: Peter Memishian , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <47D05B5A.5060406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1537 Sowmini.Varadhan@Sun.COM wrote: > On (03/06/08 11:26), Garrett D'Amore wrote: > >>> If the concern is around the lack of error reporting, the synopsis >>> of mac_register_priv_prop can be changed to return an int, with 0 >>> return status indicating success, and EEXIST indicating that the >>> registered name is a duplicate. >>> >> Probably not of much value, IMO. (We need to be trying to wean >> developers off of private properties and ndd, and if I can avoid having >> to have error checks in the driver, it will make for >> shorter/cleaner/simpler code in the driver -- that's a good thing IMO.) >> > > I could not agree more. > > >> I'd like to ensure that the "names" passed to mac_register_priv_prop >> also start with an underscore. >> > > And have mac_ndd shim strip out (or add in) the "_" prefix to retain > compatibility with existing snv output (or input) for the same command? > Actually, I'm still unconvinced about the need to support "private" or "non-canonical" properties via ndd. I think that in the new world, folks should use dladm, which includes a programmatic API via libdladm. I know that ndd is widely used for MII properties (and perhaps MTU), but I remain unconvinced that the folks who are using it today or other things would need to continue to do so given the option of a dladm based equivalent. But if we assume that we do want to support these nasty things via ndd, then I guess using the stripping is not a terrible alternative. -- Garrett From sowmini.varadhan@sun.com Thu Mar 6 13:36:17 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26LaHiE007056 for ; Thu, 6 Mar 2008 13:36:17 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26LaFZc039102; Thu, 6 Mar 2008 14:36:16 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0070DW0GFO00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 13:36:16 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB002YSW0FZM60@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 13:36:15 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26LaETP057194; Thu, 06 Mar 2008 16:36:14 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26LKQba013589; Thu, 06 Mar 2008 16:20:26 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26LKQjO013588; Thu, 06 Mar 2008 16:20:26 -0500 (EST) Date: Thu, 06 Mar 2008 16:20:26 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47D05B5A.5060406@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" , Peter Memishian Message-id: <20080306212026.GF11550@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 977 On (03/06/08 13:00), Garrett D'Amore wrote: > then I guess using the stripping is not a terrible alternative. Ok, I will send you an updated spec soon (by tomorrow), but here is a summary of what I see as the updates: - s/DLD_PERM/MAC_PERM - s/DLD_MAP/MAC_MAP - MAC_PERM_* constants and MAC_MAP* constants will reside in - mention that the private prop implementation of non-canonical ndd params must begin with a "_", and that the ndd shim will strip out (or add in) the "_" prefix for output (or input) names With this change, mac_register_private_prop() will indeed register private props, so I don't think a name change is warranted (meem?) A separate CR shall be filed to track the following: "The larger question of where the information related to the DLD*PROP ioctls will reside, and how they shall be named (none of which are changed by this case) shall be dealt with in a separate case." Please let me know if I missed something. --Sowmini From peter.memishian@sun.com Thu Mar 6 14:15:43 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26MFgA3009201 for ; Thu, 6 Mar 2008 14:15:43 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26MFZ4L008891; Thu, 6 Mar 2008 22:15:40 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00205XU2VV00@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 15:15:38 -0700 (MST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB000GMXU1I420@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 15:15:38 -0700 (MST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26MFZw7018489; Thu, 06 Mar 2008 17:15:35 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26MFVbb359206; Thu, 06 Mar 2008 17:15:31 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m26MFVIb359142; Thu, 06 Mar 2008 17:15:31 -0500 (EST) Date: Thu, 06 Mar 2008 17:15:31 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080306212026.GF11550@quasimodo.East.Sun.COM> To: Sowmini.Varadhan@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" , Peter Memishian Reply-to: peter.memishian@sun.com Message-id: <18384.27907.396396.833379@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1122 > Ok, I will send you an updated spec soon (by tomorrow), but > here is a summary of what I see as the updates: > > - s/DLD_PERM/MAC_PERM > - s/DLD_MAP/MAC_MAP > - MAC_PERM_* constants and MAC_MAP* constants will reside in > > - mention that the private prop implementation of non-canonical > ndd params must begin with a "_", and that the ndd shim > will strip out (or add in) the "_" prefix for > output (or input) names > > With this change, mac_register_private_prop() will indeed > register private props, so I don't think a name change is > warranted (meem?) Seems fine to me. Regarding the `name' parameter to mac_register_priv_prop(): I presume the caller will not provide the `_', and the framework will internally add it? (And that a `dladm show-linkprop' would show the leading underscore?) > A separate CR shall be filed to track the following: > "The larger question of where the information related to > the DLD*PROP ioctls will reside, and how they shall be named > (none of which are changed by this case) shall be dealt with > in a separate case." -- meem From Joost.Mulders@sun.com Thu Mar 6 14:18:28 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26MISee009474 for ; Thu, 6 Mar 2008 14:18:28 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26MINKs011909 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Mar 2008 14:18:28 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0031DXYR5S00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 15:18:27 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB000YHXYOI630@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 15:18:25 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26MIOAg013627 for ; Thu, 06 Mar 2008 22:18:24 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00K01XQS1W00@fe-emea-09.sun.com> (original mail from Joost.Mulders@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 22:18:24 +0000 (GMT) Received: from panoramix.gallia ([82.204.20.246]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB00INOXYNA010@fe-emea-09.sun.com>; Thu, 06 Mar 2008 22:18:24 +0000 (GMT) Date: Thu, 06 Mar 2008 23:18:22 +0100 From: Joost Mulders Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47D05B5A.5060406@sun.com> Sender: Joost.Mulders@sun.com To: "Garrett D'Amore" Cc: Sowmini.Varadhan@sun.com, PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" , Peter Memishian Message-id: <8CA23406-FAEA-4041-98DA-213CEA9EA4F5@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.919.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> Status: RO Content-Length: 2722 On Mar 6, 2008, at 10:00 PM, Garrett D'Amore wrote: > Sowmini.Varadhan@Sun.COM wrote: >> On (03/06/08 11:26), Garrett D'Amore wrote: >> >>>> If the concern is around the lack of error reporting, the synopsis >>>> of mac_register_priv_prop can be changed to return an int, with 0 >>>> return status indicating success, and EEXIST indicating that the >>>> registered name is a duplicate. >>>> >>> Probably not of much value, IMO. (We need to be trying to wean >>> developers off of private properties and ndd, and if I can avoid >>> having >>> to have error checks in the driver, it will make for >>> shorter/cleaner/simpler code in the driver -- that's a good thing >>> IMO.) >>> >> >> I could not agree more. >> >> >>> I'd like to ensure that the "names" passed to mac_register_priv_prop >>> also start with an underscore. >>> >> >> And have mac_ndd shim strip out (or add in) the "_" prefix to retain >> compatibility with existing snv output (or input) for the same >> command? >> > > Actually, I'm still unconvinced about the need to support "private" or > "non-canonical" properties via ndd. I think that in the new world, > folks should use dladm, which includes a programmatic API via > libdladm. > > I know that ndd is widely used for MII properties (and perhaps MTU), > but > I remain unconvinced that the folks who are using it today or other > things would need to continue to do so given the option of a dladm > based > equivalent. > I would like to add a big YES to the statement above! I don't understand why we put effort in maintaining compatibilty with a mistake we made in the past. Or is just to punish ourselves for making the mistake? From a admin perspective: In daily life, I build/configure backup environments for customers. These backups often make link issues come to surface. When this happens, I pursue autoneg first. If this can't happen, I use ndd to verify that changing the link configuration indeed cures the problem. If so and if we can modunload/restart, I apply the change permanently in driver.conf. Only if we can't modunload/restart I leave an ndd init script. I don't see ndd being used that much for configuring nics and I would love to see it "just go away" as soon as dladm is available. Joost > > _______________________________________________ > brussels-dev mailing list > brussels-dev@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/brussels-dev -- Joost Mulders + email: joost.mulders@sun.com Technical Specialist + phone: +31-33-45-15701 Client Solutions + fax: +31-33-45-15734 Sun Microsystems + mobile: +31-6-5198-7268 -= Anything not done right, has to be done again =- From peter.memishian@sun.com Thu Mar 6 14:39:10 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26MdAiq010371 for ; Thu, 6 Mar 2008 14:39:10 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26Md7Dm017129; Thu, 6 Mar 2008 14:39:10 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0040FYX7OC00@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 15:39:07 -0700 (MST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB000P3YX7HX50@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 15:39:07 -0700 (MST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26Md5DU024450; Thu, 06 Mar 2008 17:39:05 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26Md4LN697138; Thu, 06 Mar 2008 17:39:04 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m26Md4DH696957; Thu, 06 Mar 2008 17:39:04 -0500 (EST) Date: Thu, 06 Mar 2008 17:39:04 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080306222528.GG11550@quasimodo.East.Sun.COM> To: Sowmini.Varadhan@sun.com Cc: Peter Memishian , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore" , "Garrett D'Amore - sun microsystems" Reply-to: peter.memishian@sun.com Message-id: <18384.29320.481871.508866@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 627 > > Seems fine to me. Regarding the `name' parameter to > > mac_register_priv_prop(): I presume the caller will not provide the `_', > > Yes. the driver will be written to be consistent with dladm's > private property expectations. the mac_ndd shim will add/delete > the "_" to deal with ND_SET/ND_GET ioctls. I see. So will dladm be able to interact with these properties? Based on some of the earlier emails in this thread, it seemed like you felt that was unnecessary (and I tend to agree), but I don't see anything in the spec that prevents it. Maybe a MAC_NDD_PROP flag to mac_register_priv_prop()? -- meem From Sowmini.Varadhan@sun.com Thu Mar 6 14:41:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26MfOUO010735 for ; Thu, 6 Mar 2008 14:41:25 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26Mf6Nk014115; Fri, 7 Mar 2008 06:41:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0040DZ0UMO00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 14:41:18 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB0008GZ0TTA20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 14:41:18 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26MfHKH010948; Thu, 06 Mar 2008 17:41:17 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26MPSR2013604; Thu, 06 Mar 2008 17:25:28 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26MPSvG013603; Thu, 06 Mar 2008 17:25:28 -0500 (EST) Date: Thu, 06 Mar 2008 17:25:28 -0500 From: Sowmini.Varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.27907.396396.833379@gargle.gargle.HOWL> To: Peter Memishian Cc: "Garrett D'Amore" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <20080306222528.GG11550@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 355 On (03/06/08 17:15), Peter Memishian wrote: > Seems fine to me. Regarding the `name' parameter to > mac_register_priv_prop(): I presume the caller will not provide the `_', Yes. the driver will be written to be consistent with dladm's private property expectations. the mac_ndd shim will add/delete the "_" to deal with ND_SET/ND_GET ioctls. --Sowmini From sowmini.varadhan@sun.com Thu Mar 6 14:45:35 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26MjYCj011075 for ; Thu, 6 Mar 2008 14:45:34 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26MjVPU022894; Thu, 6 Mar 2008 22:45:32 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00503Z7T0U00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 14:45:29 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB0003YZ7STB20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 14:45:29 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26MjRHj012134; Thu, 06 Mar 2008 17:45:27 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m26MTdBk013611; Thu, 06 Mar 2008 17:29:39 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m26MTdTT013610; Thu, 06 Mar 2008 17:29:39 -0500 (EST) Date: Thu, 06 Mar 2008 17:29:39 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <8CA23406-FAEA-4041-98DA-213CEA9EA4F5@sun.com> To: Joost Mulders Cc: "Garrett D'Amore" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" , Peter Memishian Message-id: <20080306222939.GH11550@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <8CA23406-FAEA-4041-98DA-213CEA9EA4F5@sun.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 810 On (03/06/08 23:18), Joost Mulders wrote: > > I remain unconvinced that the folks who are using it today or other > > things would need to continue to do so given the option of a dladm > > based > > equivalent. > > > > I would like to add a big YES to the statement above! > > I don't understand why we put effort in maintaining compatibilty with > a mistake we made in the past. Or is just to punish ourselves for > making the mistake? The idea is to clean up the existing ndd code in drivers to deal with these ioctls, while allowing scripts (and C code out there) that already has calls to ndd (or the underlying ioctl itself) embedded in them. After this is putback, drivers that have nd_param_t related swill today will be free of such code, and the ndd callers will not even notice --Sowmini From gdamore@sun.com Thu Mar 6 14:55:55 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26MttNp011767 for ; Thu, 6 Mar 2008 14:55:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26Mtseg021341 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Mar 2008 14:55:55 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0050NZP6XT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 15:55:54 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB000G0ZP4HU60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 15:55:52 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26Mtqtd023954 for ; Thu, 06 Mar 2008 14:55:52 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00501ZMHY200@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 14:55:52 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB00JIGZOV9K40@fe-sfbay-09.sun.com>; Thu, 06 Mar 2008 14:55:44 -0800 (PST) Date: Thu, 06 Mar 2008 14:53:29 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080306222939.GH11550@quasimodo.East.Sun.COM> Sender: Garrett.Damore@sun.com To: Sowmini.Varadhan@sun.com Cc: Joost Mulders , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" , Peter Memishian Message-id: <47D075E9.7040600@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <8CA23406-FAEA-4041-98DA-213CEA9EA4F5@sun.com> <20080306222939.GH11550@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1924 Sowmini.Varadhan@Sun.COM wrote: > On (03/06/08 23:18), Joost Mulders wrote: > >>> I remain unconvinced that the folks who are using it today or other >>> things would need to continue to do so given the option of a dladm >>> based >>> equivalent. >>> >>> >> I would like to add a big YES to the statement above! >> >> I don't understand why we put effort in maintaining compatibilty with >> a mistake we made in the past. Or is just to punish ourselves for >> making the mistake? >> > > The idea is to clean up the existing ndd code in drivers > to deal with these ioctls, while allowing scripts (and C code > out there) that already has calls to ndd (or the underlying > ioctl itself) embedded in them. > > After this is putback, drivers that have nd_param_t related > swill today will be free of such code, and the ndd callers > will not even notice > This is all good. But some swill will necessarily remain in the framework itself. I would dearly love to eradicate ndd for link layer tunables altogether. Continuing to support every bizzaro tunable (or mispelled common tunable) in perpetuity seems like a high cost to pay. FWIW, I don't think the ndd ioctls have *ever* been published externally. The internal consumers I know of are either in ON, or can (and should) be changed -- SunVTS comes to mind. (And in the SunVTS case, I think it only uses those MII tunables I already talked about -- it doesn't use any driver specific tunables via NDD, at least the last time I looked at the various network related SunVTS tests.) Put another way, except for specific contracts or known cases (SunVTS), there ought not be any consumers of ndd ioctls. Use of the ndd binary in scripts is another matter entirely, but even that type of use has historically been quite limited, and I doubt you'll find many, if any, scripts that access it for other than MII or MTU. -- Garrett From gdamore@sun.com Thu Mar 6 14:58:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26Mw4k9011805 for ; Thu, 6 Mar 2008 14:58:04 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26Mw0au021409 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 7 Mar 2008 06:58:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0060JZSP2800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 15:58:01 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB000NOZSOHU60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 15:58:00 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26Mw0he020779 for ; Thu, 06 Mar 2008 14:58:00 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00001ZJ5EX00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 14:58:00 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB004E4ZSJ43A0@fe-sfbay-10.sun.com>; Thu, 06 Mar 2008 14:58:00 -0800 (PST) Date: Thu, 06 Mar 2008 14:55:41 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.29320.481871.508866@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: peter.memishian@sun.com Cc: Sowmini.Varadhan@sun.com, PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <47D0766D.4000009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1138 Peter Memishian wrote: > > > Seems fine to me. Regarding the `name' parameter to > > > mac_register_priv_prop(): I presume the caller will not provide the `_', > > > > Yes. the driver will be written to be consistent with dladm's > > private property expectations. the mac_ndd shim will add/delete > > the "_" to deal with ND_SET/ND_GET ioctls. > > I see. > > So will dladm be able to interact with these properties? Based on some of > the earlier emails in this thread, it seemed like you felt that was > unnecessary (and I tend to agree), but I don't see anything in the spec > that prevents it. Maybe a MAC_NDD_PROP flag to mac_register_priv_prop()? > In earlier conversations, I was indicating that dladm needed (or would need at some point) a way to enumerate "private" properties (quite apart from ndd), so I tried to convince Sowmini to keep the APIs general. I don't think we should be exposing *any* feature via ndd that we don't expose via dladm as well... in fact, I *would* like ndd to be a strict subset of functionality available with dladm. (The smaller the subset, the better, IMO.) -- Garrett From Peter.Memishian@sun.com Thu Mar 6 15:03:24 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26N3Opn012173 for ; Thu, 6 Mar 2008 15:03:24 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26N3MZS025532; Thu, 6 Mar 2008 15:03:23 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXC00B1101L6700@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 15:03:21 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXC002HS01JZIE0@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 15:03:20 -0800 (PST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26N3HrA017173; Thu, 06 Mar 2008 18:03:17 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26N3Hb1006945; Thu, 06 Mar 2008 18:03:17 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m26N3GM5006925; Thu, 06 Mar 2008 18:03:16 -0500 (EST) Date: Thu, 06 Mar 2008 18:03:16 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <47D0766D.4000009@sun.com> To: "Garrett D'Amore" Cc: Peter.Memishian@sun.com, Sowmini.Varadhan@sun.com, PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Reply-to: Peter.Memishian@sun.com Message-id: <18384.30772.810916.62430@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> <47D0766D.4000009@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 900 > In earlier conversations, I was indicating that dladm needed (or would > need at some point) a way to enumerate "private" properties (quite apart > from ndd), so I tried to convince Sowmini to keep the APIs general. > > I don't think we should be exposing *any* feature via ndd that we don't > expose via dladm as well... in fact, I *would* like ndd to be a strict > subset of functionality available with dladm. (The smaller the subset, > the better, IMO.) But in this case ndd can be a strict subset without requiring dladm to have identical tunables. There are already better ways (e.g., the flowctrl [agh, I wish there were more vowels in that] link property) to accomplish the same end-result as these ndd legacy tunables, so I'd rather we didn't saddle the dladm show-linkprop output with them forever. In other words, I don't want show-linkprop to become a dump. -- meem From gdamore@opensolaris.org Thu Mar 6 15:12:37 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26NCaqU012466 for ; Thu, 6 Mar 2008 15:12:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26NCJGN028655 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 7 Mar 2008 07:12:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXC00B050GVF100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 15:12:31 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXC002UY0GTZMC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Mar 2008 15:12:29 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26Mtcdm008185 for ; Thu, 06 Mar 2008 23:12:28 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP id BT-MMP-275738 for PSARC-ext@sun.com; Thu, 06 Mar 2008 23:12:28 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.sun.com with ESMTP id BT-MMP-4269002 for PSARC-ext@sun.com; Thu, 06 Mar 2008 23:12:28 +0000 (Z) Received: from outbound-mail-120.bluehost.com ([69.89.18.6] [69.89.18.6]) by relay4i.sun.com id BT-MMP-4726592 for PSARC-ext@sun.com; Thu, 06 Mar 2008 23:12:28 +0000 (Z) Received: (qmail 4444 invoked by uid 0); Thu, 06 Mar 2008 23:12:26 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by outboundproxy3.bluehost.com with SMTP; Thu, 06 Mar 2008 23:12:26 +0000 Received: from sca-ea-fw-1.sun.com ([192.18.43.225] helo=[10.7.251.172]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JXPGE-0007Xs-Nr; Thu, 06 Mar 2008 16:12:26 -0700 Date: Thu, 06 Mar 2008 15:10:04 -0800 From: "Garrett D'Amore" Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.30772.810916.62430@gargle.gargle.HOWL> To: peter.memishian@sun.com Cc: "Garrett D'Amore" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, Sowmini.Varadhan@sun.com, "Garrett D'Amore - sun microsystems" Reply-to: gdamore@opensolaris.org Message-id: <47D079CC.6090009@opensolaris.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 192.18.43.225 authed with garrett+damore.org} X-Antispam: No, score=-2.6/5.0, scanned in 0.079sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200803050524.m255O1eS011725@sac.sfbay.sun.com> <18383.24723.868952.124862@gargle.gargle.HOWL> <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> <47D0766D.4000009@sun.com> <18384.30772.810916.62430@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2224 Peter Memishian wrote: > > In earlier conversations, I was indicating that dladm needed (or would > > need at some point) a way to enumerate "private" properties (quite apart > > from ndd), so I tried to convince Sowmini to keep the APIs general. > > > > I don't think we should be exposing *any* feature via ndd that we don't > > expose via dladm as well... in fact, I *would* like ndd to be a strict > > subset of functionality available with dladm. (The smaller the subset, > > the better, IMO.) > > But in this case ndd can be a strict subset without requiring dladm to > have identical tunables. There are already better ways (e.g., the > flowctrl [agh, I wish there were more vowels in that] link property) to > accomplish the same end-result as these ndd legacy tunables, so I'd rather > we didn't saddle the dladm show-linkprop output with them forever. In > other words, I don't want show-linkprop to become a dump. > I understand *that* motivation. And frankly, the significant question I ask here is, if we have a property that does what is required (e.g. flowctrl), then *WHY* are we going to have even the remotest attempt to support some "alternate" properties that accomplish the same thing. This is like the variants of spelling errors or different - vs. _ word breaks. Its ridiculous that we should be burning any time whatsoever on those properties. If there is some weird spelling/punctuation that is "quasi-standard" and scattered around in scripts, then it should be supported (translated) internally by the framework, without asking drivers to export a redundant property. If it isn't general enough to be useful in the framework, then I *strongly* suspect that there is no compelling reason why any hardware instance would need it. On the other hand, the properties that are interesting are hardware-specific tunables (e.g. some TX FIFO threshold tunable). And those should be accessible by dladm. (Notably, I'm not sure they need to be exposed via ndd. I still think we should be doing everything possible to minimize the amount of stuff we expose or support via ndd, and strongly encouraging developers and users to steer away from it.) -- Garrett From sowmini.varadhan@sun.com Thu Mar 6 18:17:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m272HhUu018093 for ; Thu, 6 Mar 2008 18:17:44 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m272Hb6d014129; Fri, 7 Mar 2008 02:17:41 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXC0040191EHG00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 18:17:38 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXC000OE91ET0C0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 18:17:38 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m272HaIX008081; Thu, 06 Mar 2008 21:17:37 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m2721kHg013652; Thu, 06 Mar 2008 21:01:46 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m2721k8f013651; Thu, 06 Mar 2008 21:01:46 -0500 (EST) Date: Thu, 06 Mar 2008 21:01:46 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.29320.481871.508866@gargle.gargle.HOWL> To: Peter Memishian Cc: PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore" , "Garrett D'Amore - sun microsystems" Message-id: <20080307020146.GI11550@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 1386 On (03/06/08 17:39), Peter Memishian wrote: > > > > Seems fine to me. Regarding the `name' parameter to > > > mac_register_priv_prop(): I presume the caller will not provide the `_', > > > > Yes. the driver will be written to be consistent with dladm's > > private property expectations. the mac_ndd shim will add/delete > > the "_" to deal with ND_SET/ND_GET ioctls. > > I see. > > So will dladm be able to interact with these properties? If we follow the solution above (prefixing the props with _), then yes. > Based on some of > the earlier emails in this thread, it seemed like you felt that was > unnecessary (and I tend to agree), but I don't see anything in the > spec > that prevents it. Maybe a MAC_NDD_PROP flag to > mac_register_priv_prop()? If we expect the driver to pass the "MAC_NDD_PROP" flag, then we only have advisory protection from exposing these via dladm. If we want mandatory protection, then we'd have to use some other method (such as the omitting the "_" solution for ndd props that I initially proposed). I think we should either choose to let dladm have access to these non-canonical props (which is useful because dladm brings persistence, and will let you look at default values) or enforce that it cannot access them.. having an optional flag creates one more confusing parameter, and a source of inconsistent behavior. --Sowmini From sowmini.varadhan@sun.com Thu Mar 6 18:23:58 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m272Nwrh018131 for ; Thu, 6 Mar 2008 18:23:58 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m272NuBV047461; Thu, 6 Mar 2008 19:23:57 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXC00K099BW7P00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 18:23:56 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXC00CUR9BW4GA0@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 18:23:56 -0800 (PST) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m272NtKR009063; Thu, 06 Mar 2008 21:23:55 -0500 (EST) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m27286pd013661; Thu, 06 Mar 2008 21:08:06 -0500 (EST) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m27286ub013660; Thu, 06 Mar 2008 21:08:06 -0500 (EST) Date: Thu, 06 Mar 2008 21:08:06 -0500 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.30772.810916.62430@gargle.gargle.HOWL> To: Peter Memishian Cc: "Garrett D'Amore" , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore - sun microsystems" Message-id: <20080307020806.GJ11550@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> <47D0766D.4000009@sun.com> <18384.30772.810916.62430@gargle.gargle.HOWL> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 820 On (03/06/08 18:03), Peter Memishian wrote: > we didn't saddle the dladm show-linkprop output with them forever. In > other words, I don't want show-linkprop to become a dump. the legacy tunables, or private props will not be displayed by dladm. i.e, if I do "dladm show-linkprop", it will only display public properties. If I *know* the name of a private property, then I could obtain its values by # dladm show-linkprop -p _private_prop_name and I would be able to view its value. There have been requests from QE etc. that dladm should support some way of listing private property names, and if we choose to support this request, then we should figure out how to list the names in dladm's columnar format, but we have not crossed that bridge yet (and that is out of the scope of PSARC 2008/171). --Sowmini From peter.memishian@sun.com Thu Mar 6 20:08:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2748Q9L020173 for ; Thu, 6 Mar 2008 20:08:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2748LgY023816; Fri, 7 Mar 2008 04:08:24 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXC00803E5Z6P00@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 21:08:23 -0700 (MST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXC00E0CE5Y2T90@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 21:08:22 -0700 (MST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2748Jvk012399; Thu, 06 Mar 2008 23:08:19 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2748JUE761297; Thu, 06 Mar 2008 23:08:19 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2748JEU761278; Thu, 06 Mar 2008 23:08:19 -0500 (EST) Date: Thu, 06 Mar 2008 23:08:19 -0500 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080307020806.GJ11550@quasimodo.East.Sun.COM> To: Sowmini.Varadhan@sun.com Cc: Peter Memishian , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore" , "Garrett D'Amore - sun microsystems" Reply-to: peter.memishian@sun.com Message-id: <18384.49075.376042.103475@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> <47D0766D.4000009@sun.com> <18384.30772.810916.62430@gargle.gargle.HOWL> <20080307020806.GJ11550@quasimodo.East.Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1013 > > we didn't saddle the dladm show-linkprop output with them forever. In > > other words, I don't want show-linkprop to become a dump. > > the legacy tunables, or private props will not be displayed > by dladm. i.e, if I do "dladm show-linkprop", it will only display > public properties. If I *know* the name of a private property, > then I could obtain its values by > # dladm show-linkprop -p _private_prop_name > and I would be able to view its value. > > There have been requests from QE etc. that dladm should > support some way of listing private property names, and if > we choose to support this request, then we should figure > out how to list the names in dladm's columnar format, but > we have not crossed that bridge yet (and that is out of the > scope of PSARC 2008/171). I see. I agree it's beyond the scope of this case and I'm fine with the current behavior (though I agree with QE that there should be a mechanism provided to see the private properties). -- meem From sowmini.varadhan@sun.com Mon Mar 10 06:38:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2ADcKMi013682 for ; Mon, 10 Mar 2008 06:38:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2ADc5ue013137; Mon, 10 Mar 2008 13:38:18 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXI00I1BOJRMV00@nwk-avmta-2.sfbay.sun.com>; Mon, 10 Mar 2008 06:38:15 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXI00H92OJOL7F0@nwk-avmta-2.sfbay.sun.com>; Mon, 10 Mar 2008 06:38:13 -0700 (PDT) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2ADcCju014237; Mon, 10 Mar 2008 09:38:12 -0400 (EDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m2ADMKgg017511; Mon, 10 Mar 2008 09:22:20 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m2ADMKGT017510; Mon, 10 Mar 2008 09:22:20 -0400 (EDT) Date: Mon, 10 Mar 2008 09:22:20 -0400 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18384.29320.481871.508866@gargle.gargle.HOWL> To: Peter Memishian Cc: PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore" , "Garrett D'Amore - sun microsystems" Message-id: <20080310132220.GP4142@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 215 the latest copy of updated documents for PSARC 2008/171 can be found at http://opensolaris.org/os/project/brussels/files/nddcompat.txt This document contains updates from last week's discussion. --Sowmini From gdamore@sun.com Thu Mar 13 16:17:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2DNHd5K019949 for ; Thu, 13 Mar 2008 16:17:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2DNHcBW005529 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Mar 2008 23:17:38 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXO00E01ZDDYH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Mar 2008 16:17:37 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXO008A0ZDD7Y90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Mar 2008 16:17:37 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2DNHbSi026185 for ; Thu, 13 Mar 2008 16:17:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXO00401Z9DIH00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Mar 2008 16:17:37 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXO000H8ZD68UB0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Mar 2008 16:17:35 -0700 (PDT) Date: Thu, 13 Mar 2008 16:14:55 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/171 Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <47D9B56F.2090804@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 34 This case was approved yesterday. From peter.memishian@sun.com Wed Mar 19 15:33:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JMXJSQ004518 for ; Wed, 19 Mar 2008 15:33:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JMWu68027743; Thu, 20 Mar 2008 06:33:17 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY000J071BGV900@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 15:33:16 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY0004E11BFBEC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 15:33:15 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2JMXCdQ042808; Wed, 19 Mar 2008 18:33:12 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2JMXCdg819334; Wed, 19 Mar 2008 18:33:12 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2JMXC4T819331; Wed, 19 Mar 2008 18:33:12 -0400 (EDT) Date: Wed, 19 Mar 2008 18:33:12 -0400 From: Peter Memishian Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080310132220.GP4142@quasimodo.East.Sun.COM> To: Sowmini.Varadhan@sun.com Cc: Peter Memishian , PSARC-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore" , "Garrett D'Amore - sun microsystems" Reply-to: peter.memishian@sun.com Message-id: <18401.38056.364379.427529@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080306112431.GD11550@quasimodo.East.Sun.COM> <18384.14759.999824.809885@gargle.gargle.HOWL> <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> <20080310132220.GP4142@quasimodo.East.Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 568 [ Apologies for the late follow-up; I've been out. ] > the latest copy of updated documents for PSARC 2008/171 can > be found at > http://opensolaris.org/os/project/brussels/files/nddcompat.txt > > This document contains updates from last week's discussion. I'm a bit confused; the interfaces are still listed as "Committed", but I thought they'd been changed to "Consolidation Private"? Also, the prototype for mac_register_priv_prop() doesn't appear to have the constified/unsigned arguments we discussed. Am I looking at the right version? -- meem From sowmini.varadhan@sun.com Wed Mar 19 16:09:08 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JN97vV006556 for ; Wed, 19 Mar 2008 16:09:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JN8uuH012826; Thu, 20 Mar 2008 07:09:05 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY000J072Z2C800@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 17:09:02 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY000FMD2Z1U030@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 17:09:01 -0600 (MDT) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2JN90ac042428; Wed, 19 Mar 2008 19:09:00 -0400 (EDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m2JMr52R006040; Wed, 19 Mar 2008 18:53:05 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m2JMr5R4006039; Wed, 19 Mar 2008 18:53:05 -0400 (EDT) Date: Wed, 19 Mar 2008 18:53:05 -0400 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <18401.38056.364379.427529@gargle.gargle.HOWL> To: Peter Memishian Cc: psarc-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore" , "Garrett D'Amore - sun microsystems" Message-id: <20080319225305.GA6005@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080306185917.GH4142@quasimodo.East.Sun.COM> <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> <20080310132220.GP4142@quasimodo.East.Sun.COM> <18401.38056.364379.427529@gargle.gargle.HOWL> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 517 On (03/19/08 18:33), Peter Memishian wrote: > > I'm a bit confused; the interfaces are still listed as "Committed", but I > thought they'd been changed to "Consolidation Private"? Also, the > prototype for mac_register_priv_prop() doesn't appear to have the > constified/unsigned arguments we discussed. Am I looking at the right > version? > seems like that change got lost in the various deltas. I shall provide an update. See also: http://mail.opensolaris.org/pipermail/brussels-dev/2008-March/000795.html From sowmini.varadhan@sun.com Wed Mar 19 19:08:22 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2K28LDg010636 for ; Wed, 19 Mar 2008 19:08:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2K28Ji2009426; Thu, 20 Mar 2008 02:08:19 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY000A0TB9U1B00@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 20:08:18 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY0009NEB9U5N00@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 20:08:18 -0600 (MDT) Received: from quasimodo.East.Sun.COM (quasimodo.East.Sun.COM [129.148.174.94]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2K28HKg015184; Wed, 19 Mar 2008 22:08:17 -0400 (EDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m2K1qLlL006135; Wed, 19 Mar 2008 21:52:21 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m2K1qLGj006134; Wed, 19 Mar 2008 21:52:21 -0400 (EDT) Date: Wed, 19 Mar 2008 21:52:21 -0400 From: sowmini.varadhan@sun.com Subject: Re: [brussels-dev] Brussels: NDD compatiblity support [PSARC/2008/171 FastTrack timeout 03/11/2008] In-reply-to: <20080319225305.GA6005@quasimodo.East.Sun.COM> To: Peter Memishian Cc: psarc-ext@sun.com, brussels-dev@opensolaris.org, "Garrett D'Amore" , "Garrett D'Amore - sun microsystems" Message-id: <20080320015221.GH6005@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47D04568.4030003@sun.com> <20080306194642.GL4142@quasimodo.East.Sun.COM> <47D05B5A.5060406@sun.com> <20080306212026.GF11550@quasimodo.East.Sun.COM> <18384.27907.396396.833379@gargle.gargle.HOWL> <20080306222528.GG11550@quasimodo.East.Sun.COM> <18384.29320.481871.508866@gargle.gargle.HOWL> <20080310132220.GP4142@quasimodo.East.Sun.COM> <18401.38056.364379.427529@gargle.gargle.HOWL> <20080319225305.GA6005@quasimodo.East.Sun.COM> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@sun.com using -f User-Agent: Mutt/1.5.17 (2008-01-17) Status: RO Content-Length: 95 I've just updated http://opensolaris.org/os/project/brussels/files/nddcompat.txt --Sowmini