From sacadmin Tue Aug 12 00:05:00 2008 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 m7C750bO006269; Tue, 12 Aug 2008 00:05:00 -0700 (PDT) Received: (from eh146360@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7C750I8006265; Tue, 12 Aug 2008 00:05:00 -0700 (PDT) Date: Tue, 12 Aug 2008 00:05:00 -0700 (PDT) From: En-Hua Cecilia Hu Message-Id: <200808120705.m7C750I8006265@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Python interface to dlpi(7P) [PSARC/2008/514 Self Review] Status: RO Content-Length: 560 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Python interface to dlpi(7P) 1.2. Name of Document Author/Supplier: Author: Max Zhen 1.3 Date of This Document: 12 August, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: JDS 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Cecilia.Hu@sun.com Tue Aug 12 00:41:26 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 m7C7fPRY006593 for ; Tue, 12 Aug 2008 00:41:26 -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 m7C7fHgu016986 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 12 Aug 2008 15:41:25 +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 <0K5H00J039CXUV00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 00:41:21 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5H005CG9CV2OF0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 00:41:20 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7C7fJgl010397 for ; Tue, 12 Aug 2008 07:41:19 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5H00E019BJUT00@mail-apac.sun.com> (original mail from Cecilia.Hu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 15:41:19 +0800 (SGT) Received: from [129.158.218.98] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5H00MCF9CU9U8P@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 15:41:19 +0800 (SGT) Date: Tue, 12 Aug 2008 15:40:18 +0800 From: Cecilia Hu Subject: PSARC 2008/514 Python interface to dlpi(7P) Sender: Cecilia.Hu@sun.com To: psarc-ext@sun.com Cc: Max Zhen Reply-to: Cecilia.Hu@sun.com Message-id: <48A13E62.30005@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.9 (X11/20080128) Status: RO Content-Length: 9739 I am sponsoring this case for Max Zhen. This project is to provide a wrapper for dlpi(7p) functions that enables sending/receiving layer2 network packet directly from Python, and getting/setting link related configuration. The requested release binding is patch. The interface and architecture are clear enough to be a self-review. Of cause, if there is different opinion, I would like to shift it to a regular fast-track. Otherwise, case is "closed approved automatically". Thanks, Cecilia ------------------------------------------------------------------------ 1. Introduction 1.1. Project/Component Working Name: Python interface to dlpi(7P) 1.2. Name of Document Author/Supplier: Author: Max Zhen 1.3 Date of This Document: 11 August, 2008 4. Technical Description 4.1. Introduction This case introduces the dlpi Python module. It is a wrapper module for dlpi(7P) functions that enables sending/receiving layer2 network packet directly from Python, as well as getting/setting link related configuration. A patch binding is requested. 4.2. Python 'dlpi' module Classification of interfaces provided in this module is 'Committed'. The on-line help clearly shows all interfaces and their counterparts of dlpi functions in this module as below: CLASSES __builtin__.object link class link(__builtin__.object) | link(linkname, modes) -> link object | | Open linkname in specified mode. | Three modes are supported: PASSIVE, RAW, NATIVE. | See dlpi_open(3DLPI). | | Methods defined here: | | __init__(...) | x.__init__(...) initializes x; see x.__class__.__doc__ for signature | | bind(...) | bind(sap) -> unsigned int | | Attempts to bind the link to specified sap, or ANY_SAP. | Returns the real sap gets bound. | See dlpi_bind(3DLPI). | | disabmulti(...) | disabmulti(address) -> None | | Disable a specified multicast address on this link. | See dlpi_disabmulti(3DLPI). | | disabnotify(...) | disabnotify(handle) -> argument object, or None | | Disables the notification registration associated with handle. | You should get this handle by calling enabnotify(). | Returns the argument passed in when registering the callback, or None. | See dlpi_disabnotify(3DLPI). | | enabmulti(...) | enabmulti(address) -> None | | Enable a specified multicast address on this link. | See dlpi_enabmulti(3DLPI). | | enabnotify(...) | enabnotify(events, function[, arg]) -> unsigned long | | Enables a notification callback for the set of specified events, | which must be one or more (by a logical OR) events listed as below: | NOTE_LINK_DOWN Notify when link has gone down | NOTE_LINK_UP Notify when link has come up | NOTE_PHYS_ADDR Notify when address changes | NOTE_SDU_SIZE Notify when MTU changes | NOTE_SPEED Notify when speed changes | NOTE_PROMISC_ON_PHYS Notify when DL_PROMISC_PHYS is set | NOTE_PROMISC_OFF_PHYS Notify when DL_PROMISC_PHYS is cleared | Returns a handle for this registration. | See dlpi_enabnotify(3DLPI). | | get_bcastaddr(...) | get_bcastaddr() -> string | | Returns the broadcast address of the link. | See dlpi_info(3DLPI). | | get_fd(...) | get_fd() -> int | | Returns the integer file descriptor that can be used to directly | operate on the link. | See dlpi_fd(3DLPI). | | get_linkname(...) | get_linkname() -> string | | Returns the name of the link. | See dlpi_linkname(3DLPI). | | get_mactype(...) | get_mactype() -> unsigned char | | Returns MAC type of the link. | See for the list of possible MAC types. | See dlpi_info(3DLPI). | | get_physaddr(...) | get_physaddr(addrtype) -> string | | Addrtype can be any one of the value listed below: | FACT_PHYS_ADDR Factory physical address | CURR_PHYS_ADDR Current physical address | Returns the corresponding physical address of the link. | See dlpi_get_physaddr(3DLPI). | | get_qos_range(...) | get_qos_range() -> | (unsigned int, (int, int), (int, int), (int, int), int) | | Returns (qos type, (trans delay target, trans delay accept), | (min priority, max priority), (min protection, max protection), | residual err). | Unsupported QOS range values are set to UNKNOWN. | See dlpi_info(3DLPI). | | get_qos_select(...) | get_qos_select() -> (unsigned int, int, int, int) | | Returns (qos type, trans delay, priority, residul err). | Unsupported QOS parameters are set to UNKNOWN. | See dlpi_info(3DLPI). | | get_sap(...) | get_sap() -> unsigned int | | Returns the sap bound to this link. | See dlpi_info(3DLPI). | | get_sdu(...) | get_sdu() -> (unsigned int, unsigned int) | | Returns (max sdu, min sdu). | See dlpi_info(3DLPI). | | get_state(...) | get_state() -> unsigned int | | Returns current state of the link (either UNBOUND or IDLE). | See dlpi_info(3DLPI). | | get_timeout(...) | get_timeout() -> int | | Returns current time out value of the link. | See dlpi_info(3DLPI). | | promiscoff(...) | promiscoff(level) -> None | | Disables promiscuous mode for the link at levels: | PROMISC_PHYS Promiscuous mode at the physical level | PROMISC_SAP Promiscuous mode at the SAP level | PROMISC_MULTI Promiscuous mode for all multicast addresses | See dlpi_promiscoff(3DLPI). | | promiscon(...) | promiscon(level) -> None | | Enables promiscuous mode for the link at levels: | PROMISC_PHYS Promiscuous mode at the physical level | PROMISC_SAP Promiscuous mode at the SAP level | PROMISC_MULTI Promiscuous mode for all multicast addresses | See dlpi_promiscon(3DLPI). | | recv(...) | recv(trunksize[, timeout]) -> (string, string) | | Attempts to receive message over this link. | You need to specify the trunk size for the received message. | And you can specify timeout value in seconds. | Returns (source address, message data). | See dlpi_recv(3DLPI). | | send(...) | send(destaddr, message[, sap, minpri, maxpri]) -> None | | Attempts to send message over this link to destaddr. | You can specify new sap, and priority range (minpri, maxpri). | See dlpi_send(3DLPI). | | set_physaddr(...) | set_physaddr(address) -> None | | Sets the physical address of the link. | See dlpi_set_physaddr(3DLPI). | | set_timeout(...) | set_timeout(timeout) -> None | | Sets time out value of the link (default value: DEF_TIMEOUT). | See dlpi_set_timeout(3DLPI). | | unbind(...) | unbind() -> None | | Attempts to unbind the link from previously bound sap. | See dlpi_unbind(3DLPI). | | ---------------------------------------------------------------------- | Data and other attributes defined here: | | __new__ = | T.__new__(S, ...) -> a new object with type S, a subtype of T FUNCTIONS arptype(...) arptype(arptype) -> unsigned int Converts a DLPI MAC type to an ARP hardware type defined in See dlpi_arptype(3DLPI) iftype(...) iftype(iftype) -> unsigned int Converts a DLPI MAC type to a BSD socket interface type defined in See dlpi_iftype(3DLPI) listlink(...) listlink() -> list Returns a list containing link names of all links on the system. mactype(...) mactype(mactype) -> string Returns a string that describes the specified mactype. Valid mac types are defined in . See dlpi_mactype(3DLPI) DATA ANY_SAP = 4294967295 CURR_PHYS_ADDR = 2 DEF_TIMEOUT = 5 FACT_PHYS_ADDR = 1 IDLE = 3 NATIVE = 32 NOTE_LINK_DOWN = 8 NOTE_LINK_UP = 16 NOTE_PHYS_ADDR = 1 NOTE_PROMISC_OFF_PHYS = 4 NOTE_PROMISC_ON_PHYS = 2 NOTE_SDU_SIZE = 128 NOTE_SPEED = 256 PASSIVE = 2 PROMISC_MULTI = 3 PROMISC_PHYS = 1 PROMISC_SAP = 2 RAW = 4 UNBOUND = 0 UNKNOWN = -1 4.3. References None 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: JDS 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Sebastien.Roy@sun.com Tue Aug 12 07:50: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 m7CEo7vL017103 for ; Tue, 12 Aug 2008 07:50: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 m7CEo6EU018064 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 12 Aug 2008 08:50:06 -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 <0K5H0072BT7IBQ00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 08:50:06 -0600 (MDT) 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 <0K5H004MVT7IP250@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 08:50:06 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7CEo6bv016294 for ; Tue, 12 Aug 2008 14:50:06 +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 <0K5H00901SZ8JI00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 08:50:06 -0600 (MDT) Received: from [192.168.1.2] ([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 <0K5H003C1T7FO730@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 08:50:04 -0600 (MDT) Date: Tue, 12 Aug 2008 10:50:02 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A13E62.30005@sun.com> Sender: Sebastien.Roy@sun.com To: Cecilia.Hu@sun.com Cc: psarc-ext@sun.com, Max Zhen Message-id: <1218552602.995.22.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> Status: RO Content-Length: 471 On Tue, 2008-08-12 at 15:40 +0800, Cecilia Hu wrote: > The interface and architecture are clear enough to be a self-review. > Of cause, if there is different opinion, I would like to shift it to a > regular fast-track. Otherwise, case is "closed approved automatically". This is not entirely obvious enough for a self-review IMO. Could you please make this a fast-track; I'd like to set aside some time within the fast-track review period to review this case. -Seb From Cecilia.Hu@sun.com Tue Aug 12 20:28:07 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 m7D3S7p2011491 for ; Tue, 12 Aug 2008 20:28:07 -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 m7D3S1DI006977 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 12 Aug 2008 20:28:07 -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 <0K5I00G0HSAUAP00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 21:28:06 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5I00KBISATZ3B0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 12 Aug 2008 21:28:06 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7D3S59v018944 for ; Wed, 13 Aug 2008 03:28:05 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5I00B01S40QA00@mail-apac.sun.com> (original mail from Cecilia.Hu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 11:28:04 +0800 (SGT) Received: from [129.158.218.98] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5I0074MSARXJQ1@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 11:28:04 +0800 (SGT) Date: Wed, 13 Aug 2008 11:27:04 +0800 From: Cecilia Hu Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <1218552602.995.22.camel@seb> Sender: Cecilia.Hu@sun.com To: Sebastien Roy Cc: psarc-ext@sun.com, Max Zhen Reply-to: Cecilia.Hu@sun.com Message-id: <48A25488.1090302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218552602.995.22.camel@seb> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 688 Sebastien Roy Wrote: > On Tue, 2008-08-12 at 15:40 +0800, Cecilia Hu wrote: >> The interface and architecture are clear enough to be a self-review. >> Of cause, if there is different opinion, I would like to shift it to a >> regular fast-track. Otherwise, case is "closed approved automatically". > > This is not entirely obvious enough for a self-review IMO. Could you > please make this a fast-track; I'd like to set aside some time within > the fast-track review period to review this case. Ok. As I mentioned above, if anyone needs time to review this case, it will be change to a regular fast-track. Now, the timer is set to 08/19/2008. -- Cecilia.Hu@Sun.COM +86-10-62673947 From Sebastien.Roy@sun.com Wed Aug 13 08:32:42 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 m7DFWfFJ000879 for ; Wed, 13 Aug 2008 08:32:41 -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 m7DFWT7R000142 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 13 Aug 2008 16:32:40 +0100 (BST) 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 <0K5J00L0JPUFM400@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 08:32:39 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5J00EXIPUENW50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 08:32:38 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7DFWcjj004609 for ; Wed, 13 Aug 2008 15:32:38 +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 <0K5J00J01O9GCW00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 09:32:38 -0600 (MDT) 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 <0K5J00H3XPUCO510@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 09:32:36 -0600 (MDT) Date: Wed, 13 Aug 2008 11:32:36 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A13E62.30005@sun.com> Sender: Sebastien.Roy@sun.com To: Cecilia.Hu@sun.com Cc: psarc-ext@sun.com, Max Zhen Message-id: <1218641556.9181.34.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> Status: RO Content-Length: 5566 Max and Cecilia, This case looks good overall; I'd like a few clarifications and have a few questions/comments and nit-picks in-line: On Tue, 2008-08-12 at 15:40 +0800, Cecilia Hu wrote: > 4.2. Python 'dlpi' module > > Classification of interfaces provided in this module is 'Committed'. > The on-line help clearly shows all interfaces and their counterparts > of dlpi functions in this module as below: In documenting all of the functions, the definition of error semantics isn't brought up at all. For a Committed interface, I would expect that to be made explicit. I've asked some specific questions regarding return values in-line, but this is more of a general comment that I think needs to be addressed. > CLASSES > __builtin__.object > link > > class link(__builtin__.object) > | link(linkname, modes) -> link object > | > | Open linkname in specified mode. > | Three modes are supported: PASSIVE, RAW, NATIVE. > | See dlpi_open(3DLPI). in dlpi_open(3DLPI), the "modes" are actually "flags" that can be bitwise-OR'ed together to achieve a combination of behaviors (DLPI_PASSIVE, DLPI_RAW, and DLPI_NATIVE). I assume that this is also what's intended with "modes", although it isn't made explicit. On a related note, I'm no python expert, but aren't symbol names like "PASSIVE", "RAW", and "NATIVE" likely to clash with symbols defined by other classes potentially imported by an application? > | > | bind(...) > | bind(sap) -> unsigned int > | > | Attempts to bind the link to specified sap, or ANY_SAP. > | Returns the real sap gets bound. > | See dlpi_bind(3DLPI). Suggested rewording: "It returns the SAP that the function actually bound to, which could be different from the SAP requested." Also what happens on error? How does the application differentiate between errors and SAP values? > | > | disabmulti(...) > | disabmulti(address) -> None > | > | Disable a specified multicast address on this link. > | See dlpi_disabmulti(3DLPI). dlpi_disabmulti() can fail... > | > | enabmulti(...) > | enabmulti(address) -> None > | > | Enable a specified multicast address on this link. > | See dlpi_enabmulti(3DLPI). dlpi_enabmulti() can fail, and I think any sane application would want to know whether or not enabling multicast reception worked. Similar comment for other functions that don't have error semantics. > | > | enabnotify(...) > | enabnotify(events, function[, arg]) -> unsigned long > | > | Enables a notification callback for the set of specified > events, > | which must be one or more (by a logical OR) events listed > as below: > | NOTE_LINK_DOWN Notify when link has gone down > | NOTE_LINK_UP Notify when link has come up > | NOTE_PHYS_ADDR Notify when address changes > | NOTE_SDU_SIZE Notify when MTU changes > | NOTE_SPEED Notify when speed changes > | NOTE_PROMISC_ON_PHYS Notify when DL_PROMISC_PHYS is set > | NOTE_PROMISC_OFF_PHYS Notify when DL_PROMISC_PHYS is cleared > | Returns a handle for this registration. > | See dlpi_enabnotify(3DLPI). What happens if this fails? > | > | get_bcastaddr(...) > | get_bcastaddr() -> string > | > | Returns the broadcast address of the link. > | See dlpi_info(3DLPI). What is the link has no broadcast address? > | recv(...) > | recv(trunksize[, timeout]) -> (string, string) > | > | Attempts to receive message over this link. > | You need to specify the trunk size for the received message. > | And you can specify timeout value in seconds. > | Returns (source address, message data). > | See dlpi_recv(3DLPI). If timeout is not specified, does recv() behave as dlpi_recv() would if "msec" were 0 or -1 (i.e., does it not block, or does it block forever or until a message is received?). > | > | send(...) > | send(destaddr, message[, sap, minpri, maxpri]) -> None > | > | Attempts to send message over this link to destaddr. > | You can specify new sap, and priority range (minpri, maxpri). > | See dlpi_send(3DLPI). IMO, "you can specify new sap" is ambiguous. The idea is that a message is sent to the specified destination address and SAP. If the SAP isn't specified as the "sap" argument, then the bound SAP is used instead. At least that's what dlpi_send() does, and I think you want the same semantics. > DATA > ANY_SAP = 4294967295 > CURR_PHYS_ADDR = 2 > DEF_TIMEOUT = 5 > FACT_PHYS_ADDR = 1 > IDLE = 3 > NATIVE = 32 > NOTE_LINK_DOWN = 8 > NOTE_LINK_UP = 16 > NOTE_PHYS_ADDR = 1 > NOTE_PROMISC_OFF_PHYS = 4 > NOTE_PROMISC_ON_PHYS = 2 > NOTE_SDU_SIZE = 128 > NOTE_SPEED = 256 > PASSIVE = 2 > PROMISC_MULTI = 3 > PROMISC_PHYS = 1 > PROMISC_SAP = 2 > RAW = 4 > UNBOUND = 0 > UNKNOWN = -1 Are the values part of the committed interface? If not, then I would either remove the values from the case materials or explicitly state that only the symbol names are committed, and that their values are not an interface. -Seb From Kais.Belgaied@Sun.COM Wed Aug 13 09:15:31 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 m7DGFV1a003467 for ; Wed, 13 Aug 2008 09:15:31 -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 m7DGFSjX055114; Wed, 13 Aug 2008 10:15:28 -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 <0K5J0030HRTS1200@brm-avmta-1.central.sun.com>; Wed, 13 Aug 2008 10:15:28 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5J002VZRTR7P00@brm-avmta-1.central.sun.com>; Wed, 13 Aug 2008 10:15:28 -0600 (MDT) Received: from [129.146.11.146] (sr1-jurassic-03.SFBay.Sun.COM [129.146.11.146]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7DGFReu337464; Wed, 13 Aug 2008 09:15:27 -0700 (PDT) Date: Wed, 13 Aug 2008 09:15:27 -0700 From: Kais Belgaied Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A13E62.30005@sun.com> To: Cecilia.Hu@Sun.COM Cc: psarc-ext@Sun.COM, Max Zhen Reply-to: Kais.Belgaied@Sun.COM Message-id: <48A3089F.6060107@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 637 Cecilia Hu wrote: > I am sponsoring this case for Max Zhen. This project is to provide a > wrapper for dlpi(7p) functions that enables sending/receiving layer2 > network packet directly from Python, and getting/setting link related > configuration. The requested release binding is patch. > > The interface and architecture are clear enough to be a self-review. > Of cause, if there is different opinion, I would like to shift it to a > regular fast-track. Otherwise, case is "closed approved automatically". No so fast. Please re-open and put a timer on this. The is not an obvious case. Thanks, Kais > > > Thanks, > Cecilia From Kais.Belgaied@sun.com Wed Aug 13 09:26:50 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 m7DGQooh003907 for ; Wed, 13 Aug 2008 09:26:50 -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 m7DGQjVG060430; Wed, 13 Aug 2008 10:26:48 -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 <0K5J00309SCLYL00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Aug 2008 09:26:45 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5J00ENSSCKNTB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Aug 2008 09:26:44 -0700 (PDT) Received: from [129.146.11.146] (sr1-jurassic-03.SFBay.Sun.COM [129.146.11.146]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7DGQiWp339727; Wed, 13 Aug 2008 09:26:44 -0700 (PDT) Date: Wed, 13 Aug 2008 09:26:44 -0700 From: Kais Belgaied Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A3089F.6060107@Sun.COM> To: Kais.Belgaied@sun.com Cc: Cecilia.Hu@sun.com, psarc-ext@sun.com, Max Zhen Reply-to: Kais.Belgaied@sun.com Message-id: <48A30B44.5080001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <48A3089F.6060107@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 746 Cecilia, I see that you already did. Never mind. Kais Kais Belgaied wrote: > Cecilia Hu wrote: >> I am sponsoring this case for Max Zhen. This project is to provide a >> wrapper for dlpi(7p) functions that enables sending/receiving layer2 >> network packet directly from Python, and getting/setting link related >> configuration. The requested release binding is patch. >> >> The interface and architecture are clear enough to be a self-review. >> Of cause, if there is different opinion, I would like to shift it to a >> regular fast-track. Otherwise, case is "closed approved automatically". > No so fast. Please re-open and put a timer on this. > The is not an obvious case. > > Thanks, > Kais > > >> >> >> Thanks, >> Cecilia > > From danek.duvall@sun.com Wed Aug 13 09:35: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 m7DGZwUg004495 for ; Wed, 13 Aug 2008 09:35:58 -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 m7DGZqgt028297 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 13 Aug 2008 17:35:57 +0100 (BST) 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 <0K5J0070RSRVGS00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 09:35:55 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5J003O6SRVZM60@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 09:35:55 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7DGZr8b036494; Wed, 13 Aug 2008 09:35:53 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m7DGZra8023321; Wed, 13 Aug 2008 09:35:53 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m7DGZr89023320; Wed, 13 Aug 2008 09:35:53 -0700 (PDT) Date: Wed, 13 Aug 2008 09:35:52 -0700 From: Danek Duvall Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <1218641556.9181.34.camel@strat> To: Sebastien Roy Cc: Cecilia.Hu@sun.com, psarc-ext@sun.com, Max Zhen Message-id: <20080813163552.GZ1112@zruty.sfbay.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: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 503 On Wed, Aug 13, 2008 at 11:32:36AM -0400, Sebastien Roy wrote: > On a related note, I'm no python expert, but aren't symbol names like > "PASSIVE", "RAW", and "NATIVE" likely to clash with symbols defined by > other classes potentially imported by an application? The names are defined only in the context of the "dlpi" module, so code outside the module would need to refer to them as dlpi.PASSIVE, etc, or explicitly import the names into its own namespace, as in "from dlpi import PASSIVE". Danek From Sebastien.Roy@sun.com Wed Aug 13 09:37: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 m7DGbN2h004547 for ; Wed, 13 Aug 2008 09:37:23 -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 m7DGbNsU064932 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 13 Aug 2008 10:37:23 -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 <0K5J00403SUASP00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 10:37:22 -0600 (MDT) 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 <0K5J002DASUA7L20@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 10:37:22 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7DGbMP2017151 for ; Wed, 13 Aug 2008 16:37:22 +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 <0K5J00D01QMBD200@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Aug 2008 10:37:22 -0600 (MDT) 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 <0K5J00L33STQPT60@mail-amer.sun.com>; Wed, 13 Aug 2008 10:37:03 -0600 (MDT) Date: Wed, 13 Aug 2008 12:37:02 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <20080813163552.GZ1112@zruty.sfbay.sun.com> Sender: Sebastien.Roy@sun.com To: Danek Duvall Cc: Cecilia.Hu@sun.com, psarc-ext@sun.com, Max Zhen Message-id: <1218645422.9181.65.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <20080813163552.GZ1112@zruty.sfbay.sun.com> Status: RO Content-Length: 617 On Wed, 2008-08-13 at 09:35 -0700, Danek Duvall wrote: > On Wed, Aug 13, 2008 at 11:32:36AM -0400, Sebastien Roy wrote: > > > On a related note, I'm no python expert, but aren't symbol names like > > "PASSIVE", "RAW", and "NATIVE" likely to clash with symbols defined by > > other classes potentially imported by an application? > > The names are defined only in the context of the "dlpi" module, so code > outside the module would need to refer to them as dlpi.PASSIVE, etc, or > explicitly import the names into its own namespace, as in "from dlpi import > PASSIVE". Got it; thanks for the clarification. -Seb From Max.Zhen@Sun.COM Thu Aug 14 00:14:03 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 m7E7E3UP005219 for ; Thu, 14 Aug 2008 00:14:03 -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 m7E7E0O1037935 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 14 Aug 2008 01:14:02 -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 <0K5K00A0FXFDUW00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 00:14:01 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5K0071IXFCXP80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 00:14:01 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7E7E08W000118 for ; Thu, 14 Aug 2008 07:14:00 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5K00901X87BT00@mail-apac.sun.com> (original mail from Max.Zhen@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 15:13:59 +0800 (SGT) Received: from [129.158.218.112] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5K00FYRXF8R1KN@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 15:13:57 +0800 (SGT) Date: Thu, 14 Aug 2008 15:12:20 +0800 From: Max Zhen Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <1218641556.9181.34.camel@strat> Sender: Max.Zhen@Sun.COM To: Sebastien Roy Cc: Cecilia.Hu@Sun.COM, psarc-ext@Sun.COM Message-id: <48A3DAD4.7090609@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 7499 Sebastien Roy wrote: > Max and Cecilia, > > This case looks good overall; I'd like a few clarifications and have a > few questions/comments and nit-picks in-line: > > On Tue, 2008-08-12 at 15:40 +0800, Cecilia Hu wrote: > >> 4.2. Python 'dlpi' module >> >> Classification of interfaces provided in this module is 'Committed'. >> The on-line help clearly shows all interfaces and their counterparts >> of dlpi functions in this module as below: >> > > In documenting all of the functions, the definition of error semantics > isn't brought up at all. For a Committed interface, I would expect that > to be made explicit. I've asked some specific questions regarding > return values in-line, but this is more of a general comment that I > think needs to be addressed. > In general, error handling in Python code is done by catching the exception raised by the function it calls. It is required to do so when writing C extension for Python. So, in this dlpi module for Python, I followed the requirement by calling PyErr_SetString(PyExc_OSError, err_code_from_libdlpi_interface) to raise the exception whenever dlpi interface returns an error. So, in C, we check return value for error, but, in Python, we raise exceptions, instead. And PyErr_setString() is the standard way to raise an exception in C code for other Python code to catch and handle. > >> CLASSES >> __builtin__.object >> link >> >> class link(__builtin__.object) >> | link(linkname, modes) -> link object >> | >> | Open linkname in specified mode. >> | Three modes are supported: PASSIVE, RAW, NATIVE. >> | See dlpi_open(3DLPI). >> > > in dlpi_open(3DLPI), the "modes" are actually "flags" that can be > bitwise-OR'ed together to achieve a combination of behaviors > (DLPI_PASSIVE, DLPI_RAW, and DLPI_NATIVE). I assume that this is also > what's intended with "modes", although it isn't made explicit. > Yes, you can OR them. I'll make it more clear in the on-line help text. > On a related note, I'm no python expert, but aren't symbol names like > "PASSIVE", "RAW", and "NATIVE" likely to clash with symbols defined by > other classes potentially imported by an application? > As pointed out by Danek, these symbols is only visible in dlpi class. > >> | >> | bind(...) >> | bind(sap) -> unsigned int >> | >> | Attempts to bind the link to specified sap, or ANY_SAP. >> | Returns the real sap gets bound. >> | See dlpi_bind(3DLPI). >> > > Suggested rewording: "It returns the SAP that the function actually > bound to, which could be different from the SAP requested." OK. > Also what > happens on error? How does the application differentiate between errors > and SAP values? > An exception will be raised if there is an error. > >> | >> | disabmulti(...) >> | disabmulti(address) -> None >> | >> | Disable a specified multicast address on this link. >> | See dlpi_disabmulti(3DLPI). >> > > dlpi_disabmulti() can fail... > An exception will be raised if dlpi_disabmulti() fails. > >> | >> | enabmulti(...) >> | enabmulti(address) -> None >> | >> | Enable a specified multicast address on this link. >> | See dlpi_enabmulti(3DLPI). >> > > dlpi_enabmulti() can fail, and I think any sane application would want > to know whether or not enabling multicast reception worked. Similar > comment for other functions that don't have error semantics. > An exception will be raised if there is an error. So, application written in Python can catch the exception and handle the error. > >> | >> | enabnotify(...) >> | enabnotify(events, function[, arg]) -> unsigned long >> | >> | Enables a notification callback for the set of specified >> events, >> | which must be one or more (by a logical OR) events listed >> as below: >> | NOTE_LINK_DOWN Notify when link has gone down >> | NOTE_LINK_UP Notify when link has come up >> | NOTE_PHYS_ADDR Notify when address changes >> | NOTE_SDU_SIZE Notify when MTU changes >> | NOTE_SPEED Notify when speed changes >> | NOTE_PROMISC_ON_PHYS Notify when DL_PROMISC_PHYS is set >> | NOTE_PROMISC_OFF_PHYS Notify when DL_PROMISC_PHYS is cleared >> | Returns a handle for this registration. >> | See dlpi_enabnotify(3DLPI). >> > > What happens if this fails? > An exception will be raised if there is an error, just like others. > >> | >> | get_bcastaddr(...) >> | get_bcastaddr() -> string >> | >> | Returns the broadcast address of the link. >> | See dlpi_info(3DLPI). >> > > What is the link has no broadcast address? > If dlpi_info() fails (I get broadcast address by calling dlpi_info()), an exception will be raised accordingly. If dlpi_info() returns no error, but there is no broadcast address, a string Python object, whose length is zero, will be returned. > >> | recv(...) >> | recv(trunksize[, timeout]) -> (string, string) >> | >> | Attempts to receive message over this link. >> | You need to specify the trunk size for the received message. >> | And you can specify timeout value in seconds. >> | Returns (source address, message data). >> | See dlpi_recv(3DLPI). >> > > If timeout is not specified, does recv() behave as dlpi_recv() would if > "msec" were 0 or -1 (i.e., does it not block, or does it block forever > or until a message is received?). > Ah...I did not make it clear. The default value is -1, which means it'll block forever. I'll fix the on-line help here. > >> | >> | send(...) >> | send(destaddr, message[, sap, minpri, maxpri]) -> None >> | >> | Attempts to send message over this link to destaddr. >> | You can specify new sap, and priority range (minpri, maxpri). >> | See dlpi_send(3DLPI). >> > > IMO, "you can specify new sap" is ambiguous. The idea is that a message > is sent to the specified destination address and SAP. If the SAP isn't > specified as the "sap" argument, then the bound SAP is used instead. At > least that's what dlpi_send() does, and I think you want the same > semantics. > Yes, I'll change the on-line help text to make it clear. > >> DATA >> ANY_SAP = 4294967295 >> CURR_PHYS_ADDR = 2 >> DEF_TIMEOUT = 5 >> FACT_PHYS_ADDR = 1 >> IDLE = 3 >> NATIVE = 32 >> NOTE_LINK_DOWN = 8 >> NOTE_LINK_UP = 16 >> NOTE_PHYS_ADDR = 1 >> NOTE_PROMISC_OFF_PHYS = 4 >> NOTE_PROMISC_ON_PHYS = 2 >> NOTE_SDU_SIZE = 128 >> NOTE_SPEED = 256 >> PASSIVE = 2 >> PROMISC_MULTI = 3 >> PROMISC_PHYS = 1 >> PROMISC_SAP = 2 >> RAW = 4 >> UNBOUND = 0 >> UNKNOWN = -1 >> > > Are the values part of the committed interface? If not, then I would > either remove the values from the case materials or explicitly state > that only the symbol names are committed, and that their values are not > an interface. > Only the symbol names are committed. Yes, I need to make it more clear here. Thanks, Seb! Max > -Seb > > > From Sebastien.Roy@sun.com Thu Aug 14 06:37:00 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 m7EDb0CF016021 for ; Thu, 14 Aug 2008 06:37:00 -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 m7EDax00005819 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 14 Aug 2008 06:37:00 -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 <0K5L00J07F5NO700@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 06:36:59 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00I2EF5LVA10@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 06:36:58 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7EDavbZ015333 for ; Thu, 14 Aug 2008 13:36:57 +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 <0K5L00101EX4C600@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 07:36:57 -0600 (MDT) 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 <0K5L005VGF5KYFC0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 07:36:57 -0600 (MDT) Date: Thu, 14 Aug 2008 09:36:56 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A3DAD4.7090609@sun.com> Sender: Sebastien.Roy@sun.com To: Max Zhen Cc: Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <1218721016.10814.16.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> Status: RO Content-Length: 1277 Hi Max, I'm fine with your responses, I only have one follow-up question: On Thu, 2008-08-14 at 15:12 +0800, Max Zhen wrote: > Sebastien Roy wrote: > > In documenting all of the functions, the definition of error semantics > > isn't brought up at all. For a Committed interface, I would expect that > > to be made explicit. I've asked some specific questions regarding > > return values in-line, but this is more of a general comment that I > > think needs to be addressed. > > > In general, error handling in Python code is done by catching the > exception raised by the function it calls. It is required to do so when > writing C extension for Python. > So, in this dlpi module for Python, I followed the requirement by > calling PyErr_SetString(PyExc_OSError, err_code_from_libdlpi_interface) > to raise the exception whenever dlpi interface returns an error. > > So, in C, we check return value for error, but, in Python, we raise > exceptions, instead. And PyErr_setString() is the standard way to raise > an exception in C code for other Python code to catch and handle. Okay, and you're not introducing new exception types that may need to be part of the Committed interface (i.e., you're only throwing "standard" exceptions like RuntimeError)? Thanks, -Seb From Max.Zhen@sun.com Thu Aug 14 06:44:02 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 m7EDi1Rr016762 for ; Thu, 14 Aug 2008 06:44:01 -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 m7EDhv5n004202 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 14 Aug 2008 14:44:00 +0100 (BST) 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 <0K5L0060DFHAOY00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 07:43:58 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L004NMFH8ZU30@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 07:43:57 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7EDhuAq016494 for ; Thu, 14 Aug 2008 13:43:56 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5L00F01FFQZ300@mail-apac.sun.com> (original mail from Max.Zhen@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 21:43:56 +0800 (SGT) Received: from [129.150.144.30] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5L00MZ4FH79MKR@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 21:43:56 +0800 (SGT) Date: Thu, 14 Aug 2008 21:43:46 +0800 From: Max Zhen Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <1218721016.10814.16.camel@strat> Sender: Max.Zhen@sun.com To: Sebastien Roy Cc: Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <48A43692.60203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <1218721016.10814.16.camel@strat> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 1563 Sebastien Roy wrote: > Hi Max, > > I'm fine with your responses, I only have one follow-up question: > > On Thu, 2008-08-14 at 15:12 +0800, Max Zhen wrote: > >> Sebastien Roy wrote: >> >>> In documenting all of the functions, the definition of error semantics >>> isn't brought up at all. For a Committed interface, I would expect that >>> to be made explicit. I've asked some specific questions regarding >>> return values in-line, but this is more of a general comment that I >>> think needs to be addressed. >>> >>> >> In general, error handling in Python code is done by catching the >> exception raised by the function it calls. It is required to do so when >> writing C extension for Python. >> So, in this dlpi module for Python, I followed the requirement by >> calling PyErr_SetString(PyExc_OSError, err_code_from_libdlpi_interface) >> to raise the exception whenever dlpi interface returns an error. >> >> So, in C, we check return value for error, but, in Python, we raise >> exceptions, instead. And PyErr_setString() is the standard way to raise >> an exception in C code for other Python code to catch and handle. >> > > Okay, and you're not introducing new exception types that may need to be > part of the Committed interface (i.e., you're only throwing "standard" > exceptions like RuntimeError)? > No, I did not introduce new exception type. The type I raised is PyExc_OSError, which is a standard exception type defined by Python. And I don't see any point to create a new one here. Max > Thanks, > -Seb > > > From Sebastien.Roy@Sun.COM Thu Aug 14 06:46:10 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 m7EDkAHc016821 for ; Thu, 14 Aug 2008 06:46:10 -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 m7EDk7i5015975 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 14 Aug 2008 07:46:10 -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 <0K5L0080DFKXT300@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 06:46:09 -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 <0K5L007IVFKW7N10@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 06:46:09 -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 m7EDk8TF011701 for ; Thu, 14 Aug 2008 13:46:08 +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 <0K5L00201FAVXH00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 07:46:08 -0600 (MDT) 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 <0K5L00FOLFKVDI50@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 07:46:08 -0600 (MDT) Date: Thu, 14 Aug 2008 09:46:07 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A43692.60203@Sun.COM> Sender: Sebastien.Roy@Sun.COM To: Max Zhen Cc: Cecilia.Hu@Sun.COM, psarc-ext@Sun.COM Message-id: <1218721567.10814.20.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <1218721016.10814.16.camel@strat> <48A43692.60203@Sun.COM> Status: RO Content-Length: 265 On Thu, 2008-08-14 at 21:43 +0800, Max Zhen wrote: > No, I did not introduce new exception type. The type I raised is > PyExc_OSError, which is a standard exception type defined by Python. And > I don't see any point to create a new one here. Okay, thanks. -Seb From danek.duvall@sun.com Thu Aug 14 09:01:46 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 m7EG1jUD020355 for ; Thu, 14 Aug 2008 09:01:46 -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 m7EG1cPo028758 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 15 Aug 2008 00:01:44 +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 <0K5L0010JLUVPU00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 09:01:43 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00IC7LUVV890@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 09:01:43 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7EG1f9e023404; Thu, 14 Aug 2008 09:01:41 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m7EG1fK8005226; Thu, 14 Aug 2008 09:01:41 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m7EG1fa2005225; Thu, 14 Aug 2008 09:01:41 -0700 (PDT) Date: Thu, 14 Aug 2008 09:01:41 -0700 From: Danek Duvall Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A3DAD4.7090609@sun.com> To: Max Zhen Cc: Sebastien Roy , Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <20080814160141.GF1112@zruty.sfbay.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: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1275 On Thu, Aug 14, 2008 at 03:12:20PM +0800, Max Zhen wrote: > So, in this dlpi module for Python, I followed the requirement by > calling PyErr_SetString(PyExc_OSError, err_code_from_libdlpi_interface) > to raise the exception whenever dlpi interface returns an error. Wouldn't a specialized exception be more appropriate? That would allow people to be more specific in their error handling, and not have to wrap calls to the dlpi methods as tightly as a generic exception would force them to. You could even inherit DLPIError (or whatever) from OSError, if you like. We (the IPS team) have been finding that re-using the existing exception hierarchy has been very limiting, and are switching over to specialized exceptions. > >> | > >> | get_bcastaddr(...) > >> | get_bcastaddr() -> string > >> | > >> | Returns the broadcast address of the link. > >> | See dlpi_info(3DLPI). > >> > > > > What is the link has no broadcast address? > > > If dlpi_info() fails (I get broadcast address by calling dlpi_info()), > an exception will be raised accordingly. If dlpi_info() returns no > error, but there is no broadcast address, a string Python object, whose > length is zero, will be returned. Why not None? Danek From johnlev@barman.uk.sun.com Thu Aug 14 09:07:50 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 m7EG7kiW020668 for ; Thu, 14 Aug 2008 09:07:50 -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 m7EG7gtw001504 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 15 Aug 2008 00:07:45 +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 <0K5L00003M4S3200@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 09:07:40 -0700 (PDT) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00GOEM4RR860@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 14 Aug 2008 09:07:40 -0700 (PDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7EG7Yer018049; Thu, 14 Aug 2008 17:07:34 +0100 (BST) Received: from johnlev by barman.uk.sun.com with local (Exim 4.42) id 1KTfOW-0005Fv-BZ; Thu, 14 Aug 2008 17:09:48 +0100 X-URL: http://jurassic.eng/~johnlev/ Date: Thu, 14 Aug 2008 17:09:48 +0100 From: John Levon Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <20080814160141.GF1112@zruty.sfbay.sun.com> Sender: John Levon To: Danek Duvall Cc: Max Zhen , Cecilia.Hu@sun.com, psarc-ext@sun.com, Sebastien Roy Message-id: <20080814160948.GA20125@barman.uk.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: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> User-Agent: Mutt/1.5.6i Status: RO Content-Length: 1136 On Thu, Aug 14, 2008 at 09:01:41AM -0700, Danek Duvall wrote: > On Thu, Aug 14, 2008 at 03:12:20PM +0800, Max Zhen wrote: > > > So, in this dlpi module for Python, I followed the requirement by > > calling PyErr_SetString(PyExc_OSError, err_code_from_libdlpi_interface) > > to raise the exception whenever dlpi interface returns an error. > > Wouldn't a specialized exception be more appropriate? That would allow > people to be more specific in their error handling, and not have to wrap > calls to the dlpi methods as tightly as a generic exception would force > them to. You could even inherit DLPIError (or whatever) from OSError, if > you like. I don't get the benefit. We're returning OS errors (errno), and we have no additional information beyond errno/strerror. This would just obscure things IMHO. > We (the IPS team) have been finding that re-using the existing exception > hierarchy has been very limiting, and are switching over to specialized > exceptions. I believe you were using generic exceptions for pkg-internal exceptions though, which isn't the case here. (I might well be wrong about this). regards john From carlsonj@phorcys.east.sun.com Thu Aug 14 09:33:43 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 m7EGXhSj022107 for ; Thu, 14 Aug 2008 09:33:43 -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 m7EGXacQ027409; Thu, 14 Aug 2008 09:33:38 -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 <0K5L00315NC15F00@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Aug 2008 09:33:37 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00IZJNC0VIB0@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Aug 2008 09:33:37 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7EGXa73005164; Thu, 14 Aug 2008 12:33:36 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7EGXaiv005161; Thu, 14 Aug 2008 12:33:36 -0400 (EDT) Date: Thu, 14 Aug 2008 12:33:36 -0400 From: James Carlson Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <20080814160948.GA20125@barman.uk.sun.com> To: John Levon Cc: Danek Duvall , Cecilia.Hu@sun.com, psarc-ext@sun.com, Max Zhen , Sebastien Roy Message-id: <18596.24160.695864.354025@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> Status: RO Content-Length: 1255 John Levon writes: > On Thu, Aug 14, 2008 at 09:01:41AM -0700, Danek Duvall wrote: > > Wouldn't a specialized exception be more appropriate? That would allow > > people to be more specific in their error handling, and not have to wrap > > calls to the dlpi methods as tightly as a generic exception would force > > them to. You could even inherit DLPIError (or whatever) from OSError, if > > you like. > > I don't get the benefit. We're returning OS errors (errno), and we have no > additional information beyond errno/strerror. This would just obscure > things IMHO. You do have additional information: the additional information you have is that the error came from libdlpi, not just the OS itself. That might not matter too much for anything that calls your methods directly and that always includes its own exception handling, but it matters quite a lot for anything that calls a wrapper method that in turn calls your methods. Using generic exceptions potentially causes the source of the problem to get laundered away. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Sebastien.Roy@sun.com Thu Aug 14 10:19:08 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 m7EHJ8hm024557 for ; Thu, 14 Aug 2008 10:19:08 -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 m7EHJ4li003671; Thu, 14 Aug 2008 18:19:07 +0100 (BST) 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 <0K5L00401PFSV800@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Aug 2008 10:19:04 -0700 (PDT) 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 <0K5L00I9QPFSV7E0@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Aug 2008 10:19:04 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7EHJ3he019240; Thu, 14 Aug 2008 17:19:03 +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 <0K5L00801ODVE400@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM); Thu, 14 Aug 2008 11:19:03 -0600 (MDT) 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 <0K5L00M7HPFNFD90@mail-amer.sun.com>; Thu, 14 Aug 2008 11:18:59 -0600 (MDT) Date: Thu, 14 Aug 2008 13:18:58 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <20080814160948.GA20125@barman.uk.sun.com> Sender: Sebastien.Roy@sun.com To: John Levon Cc: Danek Duvall , Cecilia.Hu@sun.com, PSARC-ext@sun.com, Max Zhen Message-id: <1218734338.10814.58.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> Status: RO Content-Length: 1205 On Thu, 2008-08-14 at 17:09 +0100, John Levon wrote: > On Thu, Aug 14, 2008 at 09:01:41AM -0700, Danek Duvall wrote: > > > On Thu, Aug 14, 2008 at 03:12:20PM +0800, Max Zhen wrote: > > > > > So, in this dlpi module for Python, I followed the requirement by > > > calling PyErr_SetString(PyExc_OSError, err_code_from_libdlpi_interface) > > > to raise the exception whenever dlpi interface returns an error. > > > > Wouldn't a specialized exception be more appropriate? That would allow > > people to be more specific in their error handling, and not have to wrap > > calls to the dlpi methods as tightly as a generic exception would force > > them to. You could even inherit DLPIError (or whatever) from OSError, if > > you like. > > I don't get the benefit. We're returning OS errors (errno), and we have no > additional information beyond errno/strerror. But this isn't true. libdlpi has an entire error space separate from errno... There are dozens of error codes unrelated to errno, and it is defined as the union of DL_* errors in and DLPI_* errors in . Only if the error returned from a libdlpi function is DL_SYSERR is errno set to something meaningful. -Seb From johnlev@barman.uk.sun.com Thu Aug 14 10:21:22 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 m7EHLMw7024631 for ; Thu, 14 Aug 2008 10:21:22 -0700 (PDT) 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 m7EHLFDX033669 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 14 Aug 2008 11:21:22 -0600 (MDT) 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 <0K5L0040BPJJZ300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 14 Aug 2008 10:21:19 -0700 (PDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5L00IR7PJIVAD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 14 Aug 2008 10:21:19 -0700 (PDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7EHLCn7029592; Thu, 14 Aug 2008 18:21:12 +0100 (BST) Received: from johnlev by barman.uk.sun.com with local (Exim 4.42) id 1KTgXm-0005mt-Gz; Thu, 14 Aug 2008 18:23:26 +0100 X-URL: http://jurassic.eng/~johnlev/ Date: Thu, 14 Aug 2008 18:23:26 +0100 From: John Levon Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <1218734338.10814.58.camel@strat> Sender: John Levon To: Sebastien Roy Cc: Danek Duvall , Cecilia.Hu@sun.com, PSARC-ext@sun.com, Max Zhen Message-id: <20080814172326.GF21403@barman.uk.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: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> <1218734338.10814.58.camel@strat> User-Agent: Mutt/1.5.6i Status: RO Content-Length: 467 On Thu, Aug 14, 2008 at 01:18:58PM -0400, Sebastien Roy wrote: > But this isn't true. libdlpi has an entire error space separate from > errno... There are dozens of error codes unrelated to errno, and it is > defined as the union of DL_* errors in and DLPI_* errors in > . ???Only if the error returned from a libdlpi function is > DL_SYSERR is errno set to something meaningful. Yeah I did miss this fact, and agree now... regards john From Max.Zhen@sun.com Fri Aug 15 05:26:06 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 m7FCQ5sC002925 for ; Fri, 15 Aug 2008 05:26:05 -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 m7FCPnN6008580; Fri, 15 Aug 2008 20:26:01 +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 <0K5N00C096JCCV00@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 05:26:00 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N005T96JAET50@nwk-avmta-2.sfbay.sun.com>; Fri, 15 Aug 2008 05:25:59 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7FCPw53001498; Fri, 15 Aug 2008 12:25:58 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5N0020169UGC00@mail-apac.sun.com> (original mail from Max.Zhen@Sun.COM) ; Fri, 15 Aug 2008 20:25:58 +0800 (SGT) Received: from [129.150.144.33] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5N0074K6J8UHGD@mail-apac.sun.com>; Fri, 15 Aug 2008 20:25:58 +0800 (SGT) Date: Fri, 15 Aug 2008 20:25:46 +0800 From: Max Zhen Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <1218734338.10814.58.camel@strat> Sender: Max.Zhen@sun.com To: Sebastien Roy Cc: John Levon , Danek Duvall , Cecilia.Hu@sun.com, PSARC-ext@sun.com Message-id: <48A575CA.8000802@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> <1218734338.10814.58.camel@strat> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 1545 Sebastien Roy wrote: > On Thu, 2008-08-14 at 17:09 +0100, John Levon wrote: > >> On Thu, Aug 14, 2008 at 09:01:41AM -0700, Danek Duvall wrote: >> >> >>> On Thu, Aug 14, 2008 at 03:12:20PM +0800, Max Zhen wrote: >>> >>> >>>> So, in this dlpi module for Python, I followed the requirement by >>>> calling PyErr_SetString(PyExc_OSError, err_code_from_libdlpi_interface) >>>> to raise the exception whenever dlpi interface returns an error. >>>> >>> Wouldn't a specialized exception be more appropriate? That would allow >>> people to be more specific in their error handling, and not have to wrap >>> calls to the dlpi methods as tightly as a generic exception would force >>> them to. You could even inherit DLPIError (or whatever) from OSError, if >>> you like. >>> >> I don't get the benefit. We're returning OS errors (errno), and we have no >> additional information beyond errno/strerror. >> > > But this isn't true. libdlpi has an entire error space separate from > errno... There are dozens of error codes unrelated to errno, and it is > defined as the union of DL_* errors in and DLPI_* errors in > . Only if the error returned from a libdlpi function is > DL_SYSERR is errno set to something meaningful. > OK. I can see that it makes sense to add a new exception for libdlpi specific error. So, two exceptions can be raised from this dlpi module: + OSError - for errors set in errno + dlpi.error - for dlpi specific error other than DL_SYSERR Max > -Seb > > > From Max.Zhen@sun.com Fri Aug 15 05:30:38 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 m7FCUbT9002939 for ; Fri, 15 Aug 2008 05:30:38 -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 m7FCUPNi010309 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 15 Aug 2008 20:30:37 +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 <0K5N00F016QX3F00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 15 Aug 2008 06:30:33 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00D9X6QVUZC0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 15 Aug 2008 06:30:32 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7FCUVsi001558 for ; Fri, 15 Aug 2008 12:30:31 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5N004016ORJX00@mail-apac.sun.com> (original mail from Max.Zhen@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 15 Aug 2008 20:30:31 +0800 (SGT) Received: from [129.150.144.33] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5N00MGU6QTLR0T@mail-apac.sun.com>; Fri, 15 Aug 2008 20:30:31 +0800 (SGT) Date: Fri, 15 Aug 2008 20:30:19 +0800 From: Max Zhen Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <20080814160141.GF1112@zruty.sfbay.sun.com> Sender: Max.Zhen@sun.com To: Danek Duvall Cc: Sebastien Roy , Cecilia.Hu@sun.com, PSARC-ext@sun.com Message-id: <48A576DB.9010000@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: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 354 >> ails (I get broadcast address by calling dlpi_info()), >> an exception will be raised accordingly. If dlpi_info() returns no >> error, but there is no broadcast address, a string Python object, whose >> length is zero, will be returned. >> > > Why not None? > OK. Will return None Python object when there is no broadcast. Max > Danek > From Max.Zhen@Sun.COM Mon Aug 18 08:05: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 m7IF5CdR026350 for ; Mon, 18 Aug 2008 08:05:12 -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 m7IF5BKq022866; Mon, 18 Aug 2008 08:05:11 -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 <0K5S00501XWN9K00@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Aug 2008 08:05:11 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5S003CPXWLBK40@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Aug 2008 08:05:10 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7IF59OL015608; Mon, 18 Aug 2008 15:05:09 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5S00101XSVCJ00@mail-apac.sun.com> (original mail from Max.Zhen@Sun.COM) ; Mon, 18 Aug 2008 23:05:09 +0800 (SGT) Received: from [129.150.154.25] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5S007BLXWGUH4K@mail-apac.sun.com>; Mon, 18 Aug 2008 23:05:09 +0800 (SGT) Date: Mon, 18 Aug 2008 23:04:51 +0800 From: Max Zhen Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A575CA.8000802@Sun.COM> Sender: Max.Zhen@Sun.COM To: Sebastien Roy Cc: John Levon , Danek Duvall , Cecilia.Hu@Sun.COM, psarc-ext@Sun.COM Message-id: <48A98F93.2020801@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> <1218734338.10814.58.camel@strat> <48A575CA.8000802@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 1153 >> >> But this isn't true. libdlpi has an entire error space separate from >> errno... There are dozens of error codes unrelated to errno, and it is >> defined as the union of DL_* errors in and DLPI_* errors in >> . Only if the error returned from a libdlpi function is >> DL_SYSERR is errno set to something meaningful. >> > OK. I can see that it makes sense to add a new exception for libdlpi > specific error. > So, two exceptions can be raised from this dlpi module: > + OSError - for errors set in errno > + dlpi.error - for dlpi specific error other than DL_SYSERR After some off-line discussion w/ Danek, we agree that it makes sense to only raise one specific dlpi exception. So, only one exception will be raise in this module: dlpi.error The accompanying value is: (dlpi_error_number, string), when it is caused by a dlpi specific error, or, (DL_SYSERR, errno, string) when the error is coming from a system call. The dlpi_error_number is the error return value, other than DL_SYSERR, from dlpi_*. The string is used to describe what went wrong during the call. Max > > Max >> -Seb >> >> >> From gdamore@sun.com Mon Aug 18 08:21:03 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 m7IFL2hn026663 for ; Mon, 18 Aug 2008 08:21:03 -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 m7IFKpdK023590; Mon, 18 Aug 2008 23:21:00 +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 <0K5S00C07YMXFB00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Aug 2008 08:20:57 -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 <0K5S00KF5YMWEAD0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Aug 2008 08:20:56 -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 m7IFKuHD014135; Mon, 18 Aug 2008 08:20:56 -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 <0K5S00801Y72VF00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Mon, 18 Aug 2008 08:20:56 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5S004BDYMUX160@fe-sfbay-09.sun.com>; Mon, 18 Aug 2008 08:20:55 -0700 (PDT) Date: Mon, 18 Aug 2008 08:14:49 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A98F93.2020801@Sun.COM> Sender: Garrett.Damore@sun.com To: Max Zhen Cc: Sebastien Roy , John Levon , Danek Duvall , Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <48A991E9.1030400@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> <1218734338.10814.58.camel@strat> <48A575CA.8000802@Sun.COM> <48A98F93.2020801@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2112 I finally took time out to review the case materials (I know very little about Python, although you could argue that I have a fair bit of experience with DLPI), and they look pretty good with the exception mechanism you indicate below. I guess it should be obvious to most folks that code which uses any of this will require sys_net_rawaccess or some similar privilege to do much. You might want to indicate that somewhere in the man pages for the library. (Hmm... now that I see it, libdlpi(3DLPI) has no such note in it... I think that the man page would also be improved by a note indicating that sys_net_rawaccess or similar privilege is likely to be required.) -- Garrett Max Zhen wrote: > >>> >>> But this isn't true. libdlpi has an entire error space separate from >>> errno... There are dozens of error codes unrelated to errno, and it is >>> defined as the union of DL_* errors in and DLPI_* >>> errors in >>> . Only if the error returned from a libdlpi function is >>> DL_SYSERR is errno set to something meaningful. >>> >> OK. I can see that it makes sense to add a new exception for libdlpi >> specific error. >> So, two exceptions can be raised from this dlpi module: >> + OSError - for errors set in errno >> + dlpi.error - for dlpi specific error other than DL_SYSERR > After some off-line discussion w/ Danek, we agree that it makes sense > to only raise one specific dlpi exception. So, only one exception will > be raise in this module: dlpi.error > The accompanying value is: > (dlpi_error_number, string), when it is caused by a dlpi specific > error, or, > (DL_SYSERR, errno, s > mactype(mactype) -> string > > Returns a string that describes the specified mactype. > Valid mac types are defined in . > See dlpi_mactype(3DLPI) > > tring) when the error is coming from a system call. > The dlpi_error_number is the error return value, other than DL_SYSERR, > from dlpi_*. > The string is used to describe what went wrong during the call. > > Max >> >> Max >>> -Seb >>> >>> >>> From Max.Zhen@sun.com Mon Aug 18 08:34:08 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 m7IFY8li027497 for ; Mon, 18 Aug 2008 08:34:08 -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 m7IFY1Xg004488; Mon, 18 Aug 2008 08:34:06 -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 <0K5S00L0NZ8R8I00@brm-avmta-1.central.sun.com>; Mon, 18 Aug 2008 09:34:03 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5S00JY8Z8PYA00@brm-avmta-1.central.sun.com>; Mon, 18 Aug 2008 09:34:02 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7IFY1Td016207; Mon, 18 Aug 2008 15:34:01 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5S00H01Z2FY100@mail-apac.sun.com> (original mail from Max.Zhen@Sun.COM) ; Mon, 18 Aug 2008 23:34:01 +0800 (SGT) Received: from [129.150.154.25] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5S009Z3Z8L8FPP@mail-apac.sun.com>; Mon, 18 Aug 2008 23:34:01 +0800 (SGT) Date: Mon, 18 Aug 2008 23:33:43 +0800 From: Max Zhen Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A991E9.1030400@sun.com> Sender: Max.Zhen@sun.com To: "Garrett D'Amore" Cc: Sebastien Roy , John Levon , Danek Duvall , Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <48A99657.5090403@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> <1218734338.10814.58.camel@strat> <48A575CA.8000802@Sun.COM> <48A98F93.2020801@Sun.COM> <48A991E9.1030400@sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 2378 Garrett D'Amore wrote: > I finally took time out to review the case materials (I know very > little about Python, although you could argue that I have a fair bit > of experience with DLPI), and they look pretty good with the exception > mechanism you indicate below. I guess it should be obvious to most > folks that code which uses any of this will require sys_net_rawaccess > or some similar privilege to do much. You might want to indicate that > somewhere in the man pages for the library. Good point. I'll add this indication into the on-line help of this module to remind users that they need to obtain sys_net_rawaccess in order to open a link. Thanks, Max > > > (Hmm... now that I see it, libdlpi(3DLPI) has no such note in it... I > think that the man page would also be improved by a note indicating > that sys_net_rawaccess or similar privilege is likely to be required.) > > -- Garrett > > Max Zhen wrote: >> >>>> >>>> But this isn't true. libdlpi has an entire error space separate from >>>> errno... There are dozens of error codes unrelated to errno, and >>>> it is >>>> defined as the union of DL_* errors in and DLPI_* >>>> errors in >>>> . Only if the error returned from a libdlpi function is >>>> DL_SYSERR is errno set to something meaningful. >>>> >>> OK. I can see that it makes sense to add a new exception for libdlpi >>> specific error. >>> So, two exceptions can be raised from this dlpi module: >>> + OSError - for errors set in errno >>> + dlpi.error - for dlpi specific error other than DL_SYSERR >> After some off-line discussion w/ Danek, we agree that it makes sense >> to only raise one specific dlpi exception. So, only one exception >> will be raise in this module: dlpi.error >> The accompanying value is: >> (dlpi_error_number, string), when it is caused by a dlpi specific >> error, or, >> (DL_SYSERR, errno, s >> mactype(mactype) -> string >> >> Returns a string that describes the specified mactype. >> Valid mac types are defined in . >> See dlpi_mactype(3DLPI) >> tring) when the error is coming from a system call. >> The dlpi_error_number is the error return value, other than >> DL_SYSERR, from dlpi_*. >> The string is used to describe what went wrong during the call. >> >> Max >>> >>> Max >>>> -Seb >>>> >>>> >>>> > From Sebastien.Roy@sun.com Mon Aug 18 17:17:52 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 m7J0HpDq016642 for ; Mon, 18 Aug 2008 17:17:51 -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 m7J0HQ6k019015; Tue, 19 Aug 2008 08:17:48 +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 <0K5T00207NHMGB00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Aug 2008 17:17:46 -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 <0K5T0031PNHMG6A0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Aug 2008 17:17:46 -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 m7J0Hk0N009941; Tue, 19 Aug 2008 00:17:46 +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 <0K5T00601NE4Z600@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM); Mon, 18 Aug 2008 18:17:46 -0600 (MDT) Received: from [192.168.1.2] ([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 <0K5T00DF6NHEBQE0@mail-amer.sun.com>; Mon, 18 Aug 2008 18:17:39 -0600 (MDT) Date: Mon, 18 Aug 2008 20:17:37 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <48A98F93.2020801@Sun.COM> Sender: Sebastien.Roy@sun.com To: Max Zhen Cc: Cecilia.Hu@sun.com, psarc-ext@sun.com, Danek Duvall , John Levon Message-id: <1219105057.1228.0.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> <1218734338.10814.58.camel@strat> <48A575CA.8000802@Sun.COM> <48A98F93.2020801@Sun.COM> Status: RO Content-Length: 667 On Mon, 2008-08-18 at 23:04 +0800, Max Zhen wrote: > After some off-line discussion w/ Danek, we agree that it makes sense to > only raise one specific dlpi exception. So, only one exception will be > raise in this module: dlpi.error > The accompanying value is: > (dlpi_error_number, string), when it is caused by a dlpi specific > error, or, > (DL_SYSERR, errno, string) when the error is coming from a system call. > The dlpi_error_number is the error return value, other than DL_SYSERR, > from dlpi_*. > The string is used to describe what went wrong during the call. Great, thanks for working this out, Max. This addresses all of my issues. -Seb From Cecilia.Hu@sun.com Mon Aug 18 20:58:10 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 m7J3wA4I026009 for ; Mon, 18 Aug 2008 20:58:10 -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 m7J3w3fs025263; Tue, 19 Aug 2008 11:58:07 +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 <0K5T00H09XOSSC00@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Aug 2008 20:58:04 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5T00EELXORMH20@nwk-avmta-2.sfbay.sun.com>; Mon, 18 Aug 2008 20:58:04 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7J3w2Br025787; Tue, 19 Aug 2008 03:58:02 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K5T00J01XNZR700@mail-apac.sun.com> (original mail from Cecilia.Hu@Sun.COM); Tue, 19 Aug 2008 11:58:02 +0800 (SGT) Received: from [129.158.218.98] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K5T007JKXOKUHHM@mail-apac.sun.com>; Tue, 19 Aug 2008 11:58:02 +0800 (SGT) Date: Tue, 19 Aug 2008 11:56:55 +0800 From: Cecilia Hu Subject: Re: PSARC 2008/514 Python interface to dlpi(7P) In-reply-to: <1219105057.1228.0.camel@seb> Sender: Cecilia.Hu@sun.com To: psarc-ext@sun.com Cc: Sebastien Roy , Max Zhen , Danek Duvall , John Levon Reply-to: Cecilia.Hu@sun.com Message-id: <48AA4487.90201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48A13E62.30005@sun.com> <1218641556.9181.34.camel@strat> <48A3DAD4.7090609@sun.com> <20080814160141.GF1112@zruty.sfbay.sun.com> <20080814160948.GA20125@barman.uk.sun.com> <1218734338.10814.58.camel@strat> <48A575CA.8000802@Sun.COM> <48A98F93.2020801@Sun.COM> <1219105057.1228.0.camel@seb> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 162 It seems all issues are addressed now, so spec is updated accordingly which is in case directory. Because timer is up today, this case is closed. - Cecilia