From Artem.Kachitchkin@Sun.COM Wed Mar 26 15:18:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QMI7go015412 for ; Wed, 26 Mar 2008 15:18:07 -0700 (PDT) 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 m2QMI7nB016242 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 26 Mar 2008 15:18:07 -0700 (PDT) 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 <0JYC00H1VZA55X00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 15:18:05 -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 <0JYC00H4IZA42Q00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 15:18:04 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2QMI4q6022184 for ; Wed, 26 Mar 2008 15:18:04 -0700 (PDT) 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 <0JYC00401Z6QKA00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 15:18:04 -0700 (PDT) Received: from [129.146.104.83] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYC00J0IZA1HBC0@fe-sfbay-09.sun.com>; Wed, 26 Mar 2008 15:18:02 -0700 (PDT) Date: Wed, 26 Mar 2008 15:19:00 -0700 From: Artem Kachitchkine Subject: PSARC/2008/222 Brussels persistence Sender: Artem.Kachitchkin@Sun.COM To: psarc-ext@Sun.COM Cc: brussels-dev@opensolaris.org Message-id: <47EACBD4.2060006@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/20071105) Status: RO Content-Length: 5251 I am sponsoring this fast track for myself. Requested binding is minor, timeout 04/02/2008. -Artem 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 persistence 1.2. Name of Document Author/Supplier: Author: Artem Kachitchkine 1.3 Date of This Document: 26 March, 2008 4. Technical Description 4.1. Summary PSARC/2007/429 introduced network driver properties that persist across system reboot, but not across link plumb/unplumb. This case seeks to fix that deficiency. Property persistence across reboots is currently achieved by having svc:/network/physical invoke "dladm init-linkprop" on startup, which causes all available links to plumb and properties pushed into respective drivers. Persistence across plumb/unplumb can be achieved manually: ifconfig plumb dladm init-linkprop We propose that this happens automatically each time a link is plumbed. 4.2. Details The kernel MAC layer pushes properties into drivers via mc_setprop callback. From the driver standpoint, link plumbing and unplumbing correspond, effectively, to mc_start and mc_stop callbacks. We propose that for each persistent property mc_setprop is invoked prior to mc_start, but after attach(9E) and mac_register() are completed. That way the driver can save property values in the soft state and configure the hardware in mc_start accordingly. Implementation utilizes the dlmgmtd daemon (PSARC/2006/499). A door upcall is invoked from the MAC layer, causing dlmgmtd to initiate the equivalent of "dladm init-linkprop " using libdladm. The door call returns upon operation completion. Note: The project team considered direct parsing of the persistent store (currently /etc/dladm/dataconf.conf) from the kernel, similar to the driver.conf mechanism. But this seems future unproof, as the repository might eventually move to SMF, and there is no SMF access in the kernel. Although the above should be sufficient, in practice, the way today's drivers are coded, some of them might require properties before attach(9E) completes. To make Brussels transition easier for driver maintainers, we propose to add "pull" style property retrieval, in addition to the "push" style mc_setprop callback: int mac_prop_init(dev_info_t *dip, int instance, mac_prop_handle_t *mph) Returns a handle to be used later with mac_prop_get(). The 'instance' argument has the same meaning as m_instance passed to mac_register(): most GLDv3 should use 0. void mac_prop_fini(mac_prop_handle_t mph) Releases the handle. int mac_prop_get(mac_prop_handle_t mph, const char *name, void *value, uint_t size, uint_t *rsizep) If the requested property exists in the persistent store, up to 'size' bytes are copied into 'value'. If buffer is too small, real size is returned in 'rsizep' and the function returns EAGAIN. If property does not exist in the persistent store, ENOENT is returned. These functions do not require links to be in any particular state, so can be called from attach(9E) or any other kernel context. They could also be potentially useful for virtual links in the future. 4.3 Even more details The following interfaces are less interesting in terms of architecture but are worth a mention here. Door upcall interface: command: DLMGMT_CMD_LINKPROP_INIT argument: dlmgmt_door_linkprop_init_t flag: DLMGMT_LINKPROP_MAC_ONLY return value: dlmgmt_linkprop_init_retval_t Additional flags for dld_ioc_prop_t: DLD_PROP_FLAG_MAC_ONLY This flags indicates to the MAC layer that the property passed from userland via DLDIOCSETPROP is intended for MAC only and should not be pushed into drivers via mc_setprop. Used in mac_prop_init() implementation. DLD_PROP_FLAG_MAC_NAME This flag indicates that dld should use the provided MAC name instead of link ID. Before a device is fully attached, using vanity name services for mapping can be problematic. Additional entry in dld_ioc_prop_t: char pr_macname[LIFNAMSIZ]; Used instead of the pr_linkid when DLD_PROP_FLAG_MAC_NAME is set. 4.4. Interfaces Interface | Stability ------------------------------+----------------------- mac_prop_handle_t | Consolidation Private mac_prop_init | Consolidation Private mac_prop_fini | Consolidation Private mac_prop_get | Consolidation Private DLMGMT_CMD_LINKPROP_INIT | Consolidation Private dlmgmt_door_linkprop_init_t | Consolidation Private dlmgmt_linkprop_init_retval_t | Consolidation Private DLMGMT_LINKPROP_MAC_ONLY | Consolidation Private DLD_PROP_FLAG_MAC_ONLY | Consolidation Private DLD_PROP_FLAG_MAC_NAME | Consolidation Private ------------------------------+----------------------- Release binding: minor 4.5. References PSARC/2007/429 Brussels - enhanced network driver configuration via dladm PSARC/2006/499 Clearview Nemo unification and vanity naming 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 ceri@submonkey.net Wed Mar 26 15:29:23 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 m2QMTMA7016133 for ; Wed, 26 Mar 2008 15:29:22 -0700 (PDT) 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 m2QMTL8t022211; Wed, 26 Mar 2008 16:29:22 -0600 (MDT) 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 <0JYC00F03ZSXX300@nwk-avmta-1.sfbay.Sun.COM>; Wed, 26 Mar 2008 15:29:21 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYC00LRLZSWAFA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 26 Mar 2008 15:29:21 -0700 (PDT) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2QMTKge009451; Wed, 26 Mar 2008 22:29:20 +0000 (GMT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay24i.sun.com with ESMTP id BT-MMP-1227390; Wed, 26 Mar 2008 22:29:20 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms24es.sun.com with ESMTP id BT-MMP-2476954; Wed, 26 Mar 2008 22:29:19 +0000 (Z) Received: from shrike.submonkey.net ([81.106.128.65] [81.106.128.65]) by relay24i.sun.com with ESMTP id BT-MMP-7465; Wed, 26 Mar 2008 22:29:19 +0000 (Z) Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jee7S-000IhF-HE; Wed, 26 Mar 2008 22:29:18 +0000 Date: Wed, 26 Mar 2008 22:29:18 +0000 From: Ceri Davies Subject: Re: PSARC/2008/222 Brussels persistence In-reply-to: <47EACBD4.2060006@sun.com> Sender: Ceri Davies To: Artem Kachitchkine Cc: psarc-ext@sun.com, brussels-dev@opensolaris.org Message-id: <20080326222918.GU44028@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=5G50dybFf3pRZKd7 Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=-2.6/5.0, scanned in 0.065sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47EACBD4.2060006@sun.com> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 2016 --5G50dybFf3pRZKd7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 26, 2008 at 03:19:00PM -0700, Artem Kachitchkine wrote: > I am sponsoring this fast track for myself. > Requested binding is minor, timeout 04/02/2008. >=20 > -Artem >=20 > 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 persistence > 1.2. Name of Document Author/Supplier: > Author: Artem Kachitchkine > 1.3 Date of This Document: > 26 March, 2008 > 4. Technical Description > 4.1. Summary >=20 > PSARC/2007/429 introduced network driver properties that persist across > system reboot, but not across link plumb/unplumb. This case seeks to > fix that deficiency. >=20 > Property persistence across reboots is currently achieved by having > svc:/network/physical invoke "dladm init-linkprop" on startup, which > causes all available links to plumb and properties pushed into > respective drivers. Persistence across plumb/unplumb can be > achieved manually: >=20 > ifconfig plumb > dladm init-linkprop >=20 > We propose that this happens automatically each time a link is plumbed. How do I, as an admin, plumb an interface with no configuration for diagnostic purposes? It should also be noted that it is common practice in fora such as IRC to tell users to "ifconfig -a plumb" as a somewhat harmless way to divine what interfaces they have. Is this now potentially unsafe? Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --5G50dybFf3pRZKd7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH6s4+ocfcwTS3JF8RAhSLAJ9jrDiU5W4paSBGb7aWu0Wo5RMVPACgl7H1 RvjDnnIjGOUlFPHXgyWxVwA= =GHge -----END PGP SIGNATURE----- --5G50dybFf3pRZKd7-- From Artem.Kachitchkin@sun.com Wed Mar 26 16:03:10 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 m2QN394J018624 for ; Wed, 26 Mar 2008 16:03:09 -0700 (PDT) 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 m2QN31K6026688 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 26 Mar 2008 23:03:08 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 <0JYD00J0N1D5FN00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 16:03:05 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYD00LSP1D4AAD0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 16:03:04 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2QN33UG027076 for ; Wed, 26 Mar 2008 16:03:04 -0700 (PDT) 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 <0JYD00901155EE00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 16:03:03 -0700 (PDT) Received: from [129.146.104.83] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYD00IU61D0XUF0@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 16:03:01 -0700 (PDT) Date: Wed, 26 Mar 2008 16:03:57 -0700 From: Artem Kachitchkine Subject: Re: PSARC/2008/222 Brussels persistence In-reply-to: <20080326222918.GU44028@submonkey.net> Sender: Artem.Kachitchkin@sun.com To: Ceri Davies Cc: psarc-ext@sun.com, brussels-dev@opensolaris.org Message-id: <47EAD65D.1070704@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 References: <47EACBD4.2060006@sun.com> <20080326222918.GU44028@submonkey.net> User-Agent: Thunderbird 2.0.0.6 (X11/20071105) Status: RO Content-Length: 1029 >> ifconfig plumb >> dladm init-linkprop >> >> We propose that this happens automatically each time a link is plumbed. > > How do I, as an admin, plumb an interface with no configuration for > diagnostic purposes? > > It should also be noted that it is common practice in fora such as IRC > to tell users to "ifconfig -a plumb" as a somewhat harmless way to > divine what interfaces they have. Is this now potentially unsafe? I think it is neither safer or unsafer. Functionally this is similar to today's driver.conf properties: say, you have jumbo frames enabled in bge.conf and you want to plumb bge0 without jumbo frames, what do you do? Same with setting "mtu" with dladm set-linkprop. Temporarily remove unwanted configuration bits and later restore them. Properties can be both pushed and pulled, and while you could theoretically ask userland not to push certain properties into the drivers, forbidding drivers to actively retrieve properties when they need them might be too tricky. -Artem From sowmini.varadhan@sun.com Wed Mar 26 16:30:03 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QNU3Na019755 for ; Wed, 26 Mar 2008 16:30:03 -0700 (PDT) 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 m2QNU2Ff025276 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 26 Mar 2008 16:30:03 -0700 (PDT) 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 <0JYD00K0B2M29Y00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 16:30:02 -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 <0JYD00HWI2M22F20@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 26 Mar 2008 16:30:02 -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 m2QNU1i1017021; Wed, 26 Mar 2008 19:30:01 -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 m2QN6YoK018810; Wed, 26 Mar 2008 19:06:34 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m2QN6XMX018809; Wed, 26 Mar 2008 19:06:33 -0400 (EDT) Date: Wed, 26 Mar 2008 19:06:33 -0400 From: sowmini.varadhan@sun.com Subject: Re: PSARC/2008/222 Brussels persistence In-reply-to: <47EAD65D.1070704@sun.com> To: Artem Kachitchkine Cc: Ceri Davies , psarc-ext@sun.com, brussels-dev@opensolaris.org Message-id: <20080326230633.GE18737@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: <47EACBD4.2060006@sun.com> <20080326222918.GU44028@submonkey.net> <47EAD65D.1070704@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: 192 if you want to find out what network interfaces/drivers are available, the 'dladm show-phys' and 'dladm show-link' are available and should be preferred over "ifconfig -a plumb". --Sowmini From peter.memishian@sun.com Thu Mar 27 00:46:43 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2R7khB2005361 for ; Thu, 27 Mar 2008 00:46:43 -0700 (PDT) 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 m2R7kfUj008601 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 27 Mar 2008 00:46:43 -0700 (PDT) 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 <0JYD00307PLT8G00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Mar 2008 01:46:41 -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 <0JYD0033JPLRFKD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Mar 2008 01:46:39 -0600 (MDT) 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 m2R7kbpF044496; Thu, 27 Mar 2008 03:46:37 -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 m2R7kbCR911332; Thu, 27 Mar 2008 03:46:37 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2R7kbpc911329; Thu, 27 Mar 2008 03:46:37 -0400 (EDT) Date: Thu, 27 Mar 2008 03:46:37 -0400 From: Peter Memishian Subject: re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <47EACBD4.2060006@sun.com> To: Artem Kachitchkine Cc: psarc-ext@sun.com, brussels-dev@opensolaris.org Reply-to: peter.memishian@sun.com Message-id: <18411.20701.650519.271631@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: <47EACBD4.2060006@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1285 > PSARC/2007/429 introduced network driver properties that persist across > system reboot, but not across link plumb/unplumb. This case seeks to > fix that deficiency. A nit: plumb/unplumb terminology has generally been restricted to IP interfaces rather than links (since IP interfaces actually have STREAMS modules associated with them). It'd be good if we could generally avoid using plumb/unplumb terminology with regard to links. > This flag indicates that dld should use the provided MAC name > instead of link ID. Before a device is fully attached, using > vanity name services for mapping can be problematic. So why not always use the macname? Is it to handle VLAN link properties? If so, I think that should sort itself out post-Crossbow since (as I understand things) we'll have unique macnames for VLANs then. (I presume that even if the macname is used, the property will be able to be located using the eventual linkid associated with that macname.) > Additional entry in dld_ioc_prop_t: > > char pr_macname[LIFNAMSIZ]; LIFNAMSIZ seems inappropriate here as it sizes an IP interface name. In general, MAXNAMELEN has been used for macnames (though it's clearly a bit on the large side -- I wouldn't be opposed to a MAXMACNAMELEN constant). -- meem From ceri@submonkey.net Thu Mar 27 02:20:32 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 m2R9KV9K008040 for ; Thu, 27 Mar 2008 02:20:31 -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 m2R9KJoK023120; Thu, 27 Mar 2008 17:20:28 +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 <0JYD00I09TY3YC00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 27 Mar 2008 02:20:27 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYD00DUDTY27KA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 27 Mar 2008 02:20:26 -0700 (PDT) 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 m2R8KKRX003664; Thu, 27 Mar 2008 09:20:25 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-2550277; Thu, 27 Mar 2008 09:20:25 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms48es.sun.com with ESMTP id BT-MMP-4202887; Thu, 27 Mar 2008 09:20:25 +0000 (Z) Received: from shrike.submonkey.net ([81.106.128.65] [81.106.128.65]) by relay4i.sun.com with ESMTP id BT-MMP-68883994; Thu, 27 Mar 2008 09:20:25 +0000 (Z) Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JeoHX-00021r-Um; Thu, 27 Mar 2008 09:20:23 +0000 Date: Thu, 27 Mar 2008 09:20:23 +0000 From: Ceri Davies Subject: Re: PSARC/2008/222 Brussels persistence In-reply-to: <47EAD65D.1070704@sun.com> Sender: Ceri Davies To: Artem Kachitchkine Cc: psarc-ext@sun.com, brussels-dev@opensolaris.org Message-id: <20080327092023.GV44028@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=4SRTEifjNkXp0Rce Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=-2.6/5.0, scanned in 0.063sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47EACBD4.2060006@sun.com> <20080326222918.GU44028@submonkey.net> <47EAD65D.1070704@sun.com> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1828 --4SRTEifjNkXp0Rce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 26, 2008 at 04:03:57PM -0700, Artem Kachitchkine wrote: >=20 >>> ifconfig plumb >>> dladm init-linkprop >>>=20 >>> We propose that this happens automatically each time a link is plumbed. >>=20 >> How do I, as an admin, plumb an interface with no configuration for >> diagnostic purposes? >>=20 >> It should also be noted that it is common practice in fora such as IRC >> to tell users to "ifconfig -a plumb" as a somewhat harmless way to >> divine what interfaces they have. Is this now potentially unsafe? >=20 > I think it is neither safer or unsafer. Functionally this is similar to= =20 > today's driver.conf properties: say, you have jumbo frames enabled in=20 > bge.conf and you want to plumb bge0 without jumbo frames, what do you do?= =20 > Same with setting "mtu" with dladm set-linkprop. Temporarily remove=20 > unwanted configuration bits and later restore them. >=20 > Properties can be both pushed and pulled, and while you could theoretical= ly=20 > ask userland not to push certain properties into the drivers, forbidding= =20 > drivers to actively retrieve properties when they need them might be too= =20 > tricky. Seems I have misunderstood what a property actually is; if they're bge.conf type things then I'm happy. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --4SRTEifjNkXp0Rce Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH62bXocfcwTS3JF8RAiLvAJwLgjSmBcfo1oqARDvYcyVHgUkpXACfayX8 T/Akx8oU0bn7o2oIPmvrLEo= =dvAN -----END PGP SIGNATURE----- --4SRTEifjNkXp0Rce-- From Artem.Kachitchkin@Sun.COM Thu Mar 27 11:42:45 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 m2RIgi4q023451 for ; Thu, 27 Mar 2008 11:42:44 -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 m2RIgWeQ001209 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 27 Mar 2008 18:42:43 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 <0JYE00J2RJZ49200@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Mar 2008 11:42:40 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYE00GTPJZ1Z740@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Mar 2008 11:42:37 -0700 (PDT) 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 m2RIgbKs027515 for ; Thu, 27 Mar 2008 11:42:37 -0700 (PDT) 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 <0JYE00L01JRNCK00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Mar 2008 11:42:37 -0700 (PDT) Received: from [129.150.22.48] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYE001N8JYX3FA0@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Mar 2008 11:42:33 -0700 (PDT) Date: Thu, 27 Mar 2008 11:42:00 -0700 From: Artem Kachitchkine Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <18411.20701.650519.271631@gargle.gargle.HOWL> Sender: Artem.Kachitchkin@Sun.COM To: Peter.Memishian@Sun.COM Cc: PSARC-ext@Sun.COM, brussels-dev@opensolaris.org Message-id: <47EBEA78.3030808@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 References: <47EACBD4.2060006@sun.com> <18411.20701.650519.271631@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 1439 > A nit: plumb/unplumb terminology has generally been restricted to IP > interfaces rather than links (since IP interfaces actually have STREAMS > modules associated with them). It'd be good if we could generally avoid > using plumb/unplumb terminology with regard to links. OK. > > This flag indicates that dld should use the provided MAC name > > instead of link ID. Before a device is fully attached, using > > vanity name services for mapping can be problematic. > > So why not always use the macname? Is it to handle VLAN link properties? > If so, I think that should sort itself out post-Crossbow since (as I > understand things) we'll have unique macnames for VLANs then. (I presume > that even if the macname is used, the property will be able to be located > using the eventual linkid associated with that macname.) I believe it has to do with some details of VLAN implementation in DLS. The initial Brussels case did use macname, but it was changed to linkid in "2008/056 Brussels addendum" as a result of Seb's code review comment: http://mail.opensolaris.org/pipermail/brussels-dev/2007-November/000582.html (search for "link_id_t") > > char pr_macname[LIFNAMSIZ]; > > LIFNAMSIZ seems inappropriate here as it sizes an IP interface name. In > general, MAXNAMELEN has been used for macnames (though it's clearly a bit > on the large side -- I wouldn't be opposed to a MAXMACNAMELEN constant). OK. -Artem From Sebastien.Roy@Sun.COM Thu Mar 27 12:07:58 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 m2RJ7vWY024818 for ; Thu, 27 Mar 2008 12:07:57 -0700 (PDT) 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 m2RJ7rfI013144 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 Mar 2008 19:07:56 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 <0JYE00407L56GJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 12:07:54 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYE00G2LL56RIE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 12:07:54 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2RJ7sF2000503 for ; Thu, 27 Mar 2008 19:07:54 +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 <0JYE00K01IITNM00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 13:07:54 -0600 (MDT) Received: from [192.168.1.3] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYE00859L4V0KH0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 13:07:44 -0600 (MDT) Date: Thu, 27 Mar 2008 15:07:43 -0400 From: Sebastien Roy Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <47EBEA78.3030808@sun.com> Sender: Sebastien.Roy@Sun.COM To: Artem Kachitchkine Cc: Peter.Memishian@Sun.COM, PSARC-ext@Sun.COM, brussels-dev@opensolaris.org Message-id: <47EBF07F.7050806@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 References: <47EACBD4.2060006@sun.com> <18411.20701.650519.271631@gargle.gargle.HOWL> <47EBEA78.3030808@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 1637 Artem Kachitchkine wrote: >> A nit: plumb/unplumb terminology has generally been restricted to IP >> interfaces rather than links (since IP interfaces actually have STREAMS >> modules associated with them). It'd be good if we could generally avoid >> using plumb/unplumb terminology with regard to links. > > OK. > >> > This flag indicates that dld should use the provided MAC name >> > instead of link ID. Before a device is fully attached, using >> > vanity name services for mapping can be problematic. >> >> So why not always use the macname? Is it to handle VLAN link properties? >> If so, I think that should sort itself out post-Crossbow since (as I >> understand things) we'll have unique macnames for VLANs then. (I presume >> that even if the macname is used, the property will be able to be located >> using the eventual linkid associated with that macname.) > > I believe it has to do with some details of VLAN implementation in DLS. > The initial Brussels case did use macname, but it was changed to linkid > in "2008/056 Brussels addendum" as a result of Seb's code review comment: > > http://mail.opensolaris.org/pipermail/brussels-dev/2007-November/000582.html > > (search for "link_id_t") That was not the nature of my code-review comment. The initial Brussels code, before that code-review, used link names (not MAC names). It is not sensible to pass link names down to the kernel via an ioctl interface, as the kernel has to translate that to either a datalink_id_t or a MAC name in order to use access the GLDv3 kernel objects, both of which would require a door upcall to userland to get. -Seb From Artem.Kachitchkin@sun.com Thu Mar 27 12:41:30 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 m2RJfU2Q025713 for ; Thu, 27 Mar 2008 12:41:30 -0700 (PDT) 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 m2RJfOTj028493 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 Mar 2008 19:41:28 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 <0JYE0075FMP3O200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 12:41:27 -0700 (PDT) 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 <0JYE005NKMP2K680@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 12:41:26 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2RJfQKi005105 for ; Thu, 27 Mar 2008 12:41:26 -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 <0JYE00D01M61P700@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 12:41:26 -0700 (PDT) Received: from [129.146.104.83] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYE00FA3MP1OF60@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 12:41:26 -0700 (PDT) Date: Thu, 27 Mar 2008 12:42:25 -0700 From: Artem Kachitchkine Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <47EBF07F.7050806@sun.com> Sender: Artem.Kachitchkin@sun.com To: Sebastien Roy Cc: PSARC-ext@sun.com, brussels-dev@opensolaris.org, Peter.Memishian@sun.com Message-id: <47EBF8A1.8090700@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 References: <47EACBD4.2060006@sun.com> <18411.20701.650519.271631@gargle.gargle.HOWL> <47EBEA78.3030808@sun.com> <47EBF07F.7050806@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071105) Status: RO Content-Length: 876 > That was not the nature of my code-review comment. The initial Brussels > code, before that code-review, used link names (not MAC names). It is > not sensible to pass link names down to the kernel via an ioctl > interface, as the kernel has to translate that to either a datalink_id_t > or a MAC name in order to use access the GLDv3 kernel objects, both of > which would require a door upcall to userland to get. I see. Getting back to this case, I am using MAC names, since that's what mac_init_prop() can easily derive from {devinfo,instance} and use internally to associate properties with. The userland (dlmgmtd, libdladm) should have no problem finding properties based on MAC name. So MAC passes the name to dlmgmtd via upcall and dlmgmtd bounces it right back to MAC (via DLD) with some properties attached to it. Feels pretty organic to me. -Artem From peter.memishian@sun.com Thu Mar 27 15:00:32 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 m2RM0VvW000398 for ; Thu, 27 Mar 2008 15:00:31 -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 m2RM0LIX013909 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 28 Mar 2008 06:00:30 +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 <0JYE00F01T4RUM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 16:00:27 -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 <0JYE00ATTT4QYS50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 16:00:27 -0600 (MDT) 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 m2RM0OdM064826; Thu, 27 Mar 2008 18:00:24 -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 m2RM0ORk264057; Thu, 27 Mar 2008 18:00:24 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2RM0OWT264054; Thu, 27 Mar 2008 18:00:24 -0400 (EDT) Date: Thu, 27 Mar 2008 18:00:24 -0400 From: Peter Memishian Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <47EBF07F.7050806@sun.com> To: Sebastien Roy Cc: Artem Kachitchkine , peter.memishian@sun.com, PSARC-ext@sun.com, brussels-dev@opensolaris.org Reply-to: peter.memishian@sun.com Message-id: <18412.6392.368889.816337@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: <47EACBD4.2060006@sun.com> <18411.20701.650519.271631@gargle.gargle.HOWL> <47EBEA78.3030808@sun.com> <47EBF07F.7050806@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1876 > >> > This flag indicates that dld should use the provided MAC name > >> > instead of link ID. Before a device is fully attached, using > >> > vanity name services for mapping can be problematic. > >> > >> So why not always use the macname? Is it to handle VLAN link properties? > >> If so, I think that should sort itself out post-Crossbow since (as I > >> understand things) we'll have unique macnames for VLANs then. (I presume > >> that even if the macname is used, the property will be able to be located > >> using the eventual linkid associated with that macname.) > > > > I believe it has to do with some details of VLAN implementation in DLS. > > The initial Brussels case did use macname, but it was changed to linkid > > in "2008/056 Brussels addendum" as a result of Seb's code review comment: > > > > http://mail.opensolaris.org/pipermail/brussels-dev/2007-November/000582.html > > > > (search for "link_id_t") > > That was not the nature of my code-review comment. The initial Brussels > code, before that code-review, used link names (not MAC names). It is > not sensible to pass link names down to the kernel via an ioctl > interface, as the kernel has to translate that to either a datalink_id_t > or a MAC name in order to use access the GLDv3 kernel objects, both of > which would require a door upcall to userland to get. So then could someone clarify why we must complicate the interface with two different forms of access (macname and linkid)? Is it because a macname is not unique for VLANs, and a linkid for the mac may not yet exist? If so, I guess we can live with the complexity until Crossbow integrates and then change things to always use a macname. That said, it's unclear to me whether Brussels handles link properties for VLANs and as such whether VLANs are germane to the discussion. -- meem From Artem.Kachitchkin@Sun.COM Thu Mar 27 15:26:24 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 m2RMQNTW001680 for ; Thu, 27 Mar 2008 15:26:24 -0700 (PDT) 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 m2RMQE15026257 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 28 Mar 2008 06:26:23 +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 <0JYE00301UBUJC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 15:26:18 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYE001B8UBU3340@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 15:26:18 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2RMQHZU025564 for ; Thu, 27 Mar 2008 15:26:17 -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 <0JYE00301U6GR400@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 15:26:17 -0700 (PDT) Received: from [129.146.104.83] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYE00J6JUBT6H40@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 15:26:17 -0700 (PDT) Date: Thu, 27 Mar 2008 15:27:17 -0700 From: Artem Kachitchkine Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <18412.6392.368889.816337@gargle.gargle.HOWL> Sender: Artem.Kachitchkin@Sun.COM To: Peter.Memishian@Sun.COM Cc: Sebastien Roy , PSARC-ext@Sun.COM, brussels-dev@opensolaris.org Message-id: <47EC1F45.9090509@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 References: <47EACBD4.2060006@sun.com> <18411.20701.650519.271631@gargle.gargle.HOWL> <47EBEA78.3030808@sun.com> <47EBF07F.7050806@sun.com> <18412.6392.368889.816337@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071105) Status: RO Content-Length: 979 > So then could someone clarify why we must complicate the interface with > two different forms of access (macname and linkid)? Is it because a > macname is not unique for VLANs, and a linkid for the mac may not yet > exist? If so, I guess we can live with the complexity until Crossbow > integrates and then change things to always use a macname. That said, > it's unclear to me whether Brussels handles link properties for VLANs > and as such whether VLANs are germane to the discussion. My intention was to keep interfaces flexible enough to be used in various contexts. Such as a partially attached driver instance, or a virtual link that does not exist or is in the process of coming into existence. Then again, we're talking interfaces between dladm/dlmgmt and mac/dld, their exposure is so small they are practically project private. I mean, aunt Ruth's backyard flower bed is neat and well-kempt, but she's about the only person who appreciates it :) -Artem From Peter.Memishian@Sun.COM Thu Mar 27 15:30:55 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 m2RMUsou001792 for ; Thu, 27 Mar 2008 15:30:54 -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 m2RMUnkj014860 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 Mar 2008 22:30:53 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 <0JYE0030RUJHOU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 15:30:53 -0700 (PDT) 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 <0JYE001N1UJF3340@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 15:30:52 -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 m2RMUnPI007915; Thu, 27 Mar 2008 18:30:49 -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 m2RMUnkU341657; Thu, 27 Mar 2008 18:30:49 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2RMUn0n341654; Thu, 27 Mar 2008 18:30:49 -0400 (EDT) Date: Thu, 27 Mar 2008 18:30:49 -0400 From: Peter Memishian Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <47EC1F45.9090509@sun.com> To: Artem Kachitchkine Cc: Peter.Memishian@Sun.COM, Sebastien Roy , PSARC-ext@Sun.COM, brussels-dev@opensolaris.org Reply-to: Peter.Memishian@Sun.COM Message-id: <18412.8217.163852.426369@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: <47EACBD4.2060006@sun.com> <18411.20701.650519.271631@gargle.gargle.HOWL> <47EBEA78.3030808@sun.com> <47EBF07F.7050806@sun.com> <18412.6392.368889.816337@gargle.gargle.HOWL> <47EC1F45.9090509@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 384 > Then again, we're talking interfaces between dladm/dlmgmt and mac/dld, > their exposure is so small they are practically project private. I mean, > aunt Ruth's backyard flower bed is neat and well-kempt, but she's about > the only person who appreciates it :) I thought these interfaces would rise to Committed as part of making GLDv3 public. Is that incorrect? -- meem From Artem.Kachitchkin@sun.com Thu Mar 27 15:41:07 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 m2RMf7eb001877 for ; Thu, 27 Mar 2008 15:41:07 -0700 (PDT) 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 m2RMf6Xg045975 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 Mar 2008 16:41:07 -0600 (MDT) 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 <0JYE00I1DV0FU800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 27 Mar 2008 16:41:03 -0600 (MDT) 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 <0JYE00AZ6V0FYI70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 27 Mar 2008 16:41:03 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2RMf2xv027004 for ; Thu, 27 Mar 2008 15:41:02 -0700 (PDT) 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 <0JYE00D01UX8EQ00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 27 Mar 2008 15:41:02 -0700 (PDT) Received: from [129.146.104.83] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYE00KR5V0DWME0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 27 Mar 2008 15:41:01 -0700 (PDT) Date: Thu, 27 Mar 2008 15:42:01 -0700 From: Artem Kachitchkine Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <18412.8217.163852.426369@gargle.gargle.HOWL> Sender: Artem.Kachitchkin@sun.com To: Peter.Memishian@sun.com Cc: PSARC-ext@sun.com, brussels-dev@opensolaris.org Message-id: <47EC22B9.4090207@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 References: <47EACBD4.2060006@sun.com> <18411.20701.650519.271631@gargle.gargle.HOWL> <47EBEA78.3030808@sun.com> <47EBF07F.7050806@sun.com> <18412.6392.368889.816337@gargle.gargle.HOWL> <47EC1F45.9090509@sun.com> <18412.8217.163852.426369@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071105) Status: RO Content-Length: 340 > I thought these interfaces would rise to Committed as part of making GLDv3 > public. Is that incorrect? Are dlmgmt upcalls and DLDIOCSETPROP part of GLDv3? My understanding that, of all interfaces presented in this case, only mac_prop_* are part of GLDv3 - and none of those use either MAC names, or link names, or linkids. -Artem From peter.memishian@sun.com Thu Mar 27 15:44:13 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2RMiDCk001916 for ; Thu, 27 Mar 2008 15:44:13 -0700 (PDT) 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 m2RMiCoe008091 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 Mar 2008 15:44:13 -0700 (PDT) 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 <0JYE00J0BV5O1Z00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 16:44:12 -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 <0JYE00AYSV5NYR80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 16:44:12 -0600 (MDT) 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 m2RMiAYW011889; Thu, 27 Mar 2008 18:44:10 -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 m2RMiAWW343089; Thu, 27 Mar 2008 18:44:10 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2RMiAMT343086; Thu, 27 Mar 2008 18:44:10 -0400 (EDT) Date: Thu, 27 Mar 2008 18:44:10 -0400 From: Peter Memishian Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <47EC22B9.4090207@sun.com> To: Artem Kachitchkine Cc: peter.memishian@sun.com, PSARC-ext@sun.com, brussels-dev@opensolaris.org Reply-to: peter.memishian@sun.com Message-id: <18412.9018.175783.646000@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: <47EACBD4.2060006@sun.com> <18411.20701.650519.271631@gargle.gargle.HOWL> <47EBEA78.3030808@sun.com> <47EBF07F.7050806@sun.com> <18412.6392.368889.816337@gargle.gargle.HOWL> <47EC1F45.9090509@sun.com> <18412.8217.163852.426369@gargle.gargle.HOWL> <47EC22B9.4090207@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 308 > Are dlmgmt upcalls and DLDIOCSETPROP part of GLDv3? Not part of any to-be-committed API. Sorry, I misread your original materials and thought this issue was visible to the mac_prop_() APIs. So I think what you have is fine (though I'd still like to see some gardening done here later on ;-) -- meem From Artem.Kachitchkin@sun.com Wed Apr 2 11:26:32 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 m32IQWNe013398 for ; Wed, 2 Apr 2008 11:26:32 -0700 (PDT) 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 m32IQV5q020398 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 2 Apr 2008 12:26:32 -0600 (MDT) 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 <0JYP00A09N87WF00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Apr 2008 11:26:31 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYP0039MN87WKC0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Apr 2008 11:26:31 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m32IQVCT024697 for ; Wed, 02 Apr 2008 11:26:31 -0700 (PDT) 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 <0JYP00F01MXCN000@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Apr 2008 11:26:31 -0700 (PDT) Received: from [129.146.104.83] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYP00MB7N84NS10@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Apr 2008 11:26:28 -0700 (PDT) Date: Wed, 02 Apr 2008 11:27:41 -0700 From: Artem Kachitchkine Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <47EACBD4.2060006@sun.com> Sender: Artem.Kachitchkin@sun.com To: PSARC-ext@sun.com Cc: brussels-dev@opensolaris.org Message-id: <47F3D01D.6030203@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 References: <47EACBD4.2060006@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071105) Status: RO Content-Length: 96 By request from a PSARC member, the timeout is extended until this Friday, April 4th. -Artem From Artem.Kachitchkin@Sun.COM Fri Apr 4 17:25:45 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 m350PiY1015163 for ; Fri, 4 Apr 2008 17:25:44 -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 m350PhS1001494 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 5 Apr 2008 08:25:43 +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 <0JYT00D01T6UQE00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 18:25:42 -0600 (MDT) 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 <0JYT009SKT6T1D30@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 18:25:41 -0600 (MDT) 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 m350PfGN000582 for ; Fri, 04 Apr 2008 17:25:41 -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 <0JYT00I01T2NN100@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 17:25:41 -0700 (PDT) Received: from [129.150.16.199] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT00BCDT6TCF30@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Apr 2008 17:25:41 -0700 (PDT) Date: Fri, 04 Apr 2008 17:25:52 -0700 From: Artem Kachitchkine Subject: Re: [brussels-dev] PSARC/2008/222 Brussels persistence In-reply-to: <47EACBD4.2060006@sun.com> Sender: Artem.Kachitchkin@Sun.COM To: psarc-ext@Sun.COM Cc: brussels-dev@opensolaris.org Message-id: <47F6C710.9060509@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 References: <47EACBD4.2060006@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 27 Case is approved. -Artem