From sacadmin Thu Apr 13 14:09:45 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3DL9jIQ005664 for ; Thu, 13 Apr 2006 14:09:45 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXO00701IPJ5R@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Thu, 13 Apr 2006 17:09:45 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXO000IMIS8NY@bur-mail2.east.sun.com>; Thu, 13 Apr 2006 17:09:45 -0400 (EDT) Date: Thu, 13 Apr 2006 17:09:44 -0400 From: Sebastien Roy Subject: 2006/249 Nemo Changes for Binary Compatibility To: PSARC@sac.sfbay.sun.com Cc: clearview-iteam@sun.com Message-id: <443EBE18.4040409@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) Status: RO Content-Length: 43157 I'm sponsoring the following fast-track for myself (and the greater Clearview I-Team.) The timer expires on 04/20/2006. This case depends on 2006/248, and 2006/248 depends on this case. Nemo Changes for Binary Compatibility ===================================== release binding: patch 1 Introduction ============== This fast-track case is part of the Clearview umbrella case (PSARC/2005/132). It modifies and makes additions to the interfaces defined in PSARC/2004/571 (Nemo - a.k.a. GLD v3). The justification for this work and its relationship to the rest of the Clearview project is discussed in that case. This case has two goals. 1. Address the problem that the GLDv3 framework cannot be extended in a binary compatible way due to the design of its MAC driver interfaces. 2. While modifying the MAC driver interfaces, add MAC driver support for the MAC-Type plugin architecture described in PSARC/2006/248 to the MAC driver interfaces. That case requires that drivers specify which MAC-Type plugin they wish to use upon registering, and register some plugin specific data. This case specifies how this will be done using mac_register(). This case and PSARC/2006/248 are therefore interdependent, and cannot integrate separately. The GLDv3 framework requires the size of internal data-structures (mac_t and mac_info_t) to be hard-coded within each driver. This will make it nearly impossible to extend the capabilities of the framework in the future without breaking binary compatibility with drivers written to the framework. This problem is outlined in bugids 6242059 ("nemo drivers must not know the size of the mac_t structure") and 6226635 ("MAC stats interface could cause problems with binary compatibility".) This is addressed by changing the way that drivers register and interact with the GLDv3 mac module. Note that these changes are not backward compatible, but because the GLDv3 interfaces are consolidation private, this type of change is acceptable. This work will be one step forward to make it possible for the interfaces to become public in the future. This case does not upgrade the stability of these interfaces. Note that throughout this case, the terminology "previous model" refers to the GLDv3 implementation before the implementation of this case, as defined in PSARC/2004/571. 2 Changes to mac_register() =========================== The cornerstone of the GLDv3 MAC driver interface is the mac_register() function, which is used by GLDv3 drivers to register MAC devices. In order to create a binary compatible interface, driver registration will be modified such that drivers will use the following four functions: mac_register_t *mac_alloc(uint_t mac_version); int mac_register(mac_register_t *, mac_handle_t *); void mac_free(mac_register_t *); int mac_unregister(mac_handle_t); In order to register, drivers will first allocate a mac_register_t structure using mac_alloc(). The sole argument to mac_alloc() _must_ be MAC_VERSION (defined in ). Passing in MAC_VERSION allows mac_alloc() to verify if the driver was compiled against a version of the GLDv3 framework which is compatible with what is running on the system. In the case of an incompatible version, mac_alloc() fails and returns NULL. If the version is compatible, it will allocate a mac_register_t structure and return a pointer to it. The m_version field of the returned structure will have been automatically set to the requested version by mac_alloc(). Drivers will then fill in the rest of the mac_register_t structure with the required information and pass it into mac_register(), which will return an opaque MAC handle for use in all other driver interface functions. The registration structure can be immediately freed after registration using the mac_free() function. When the device detaches and needs to unregister, it passes this handle into mac_unregister(). The benefit of this model is that drivers are shielded from knowing the real size of the mac_register_t structure. The GLDv3 framework can grow to include more optional information in mac_register_t (thus returning a larger structure in mac_alloc()), and drivers will only fill in the parts of the structure that they were compiled to know about, thus preserving binary compatibility. 2.1 mac_register_t ------------------ The structure of mac_register_t is: typedef struct mac_register_s { uint_t m_version; const char *m_type_ident; void *m_driver; dev_info_t *m_dip; uint_t m_instance; uint8_t *m_src_addr; uint8_t *m_dst_addr; mac_callbacks_t *m_callbacks; uint_t m_min_sdu; uint_t m_max_sdu; void *m_pdata; size_t m_pdata_size; } mac_register_t; * m_version will be set to MAC_VERSION (defined in ) by the mac_alloc() function. This allows the mac module to know what version of the MAC driver interface the driver was compiled against. Drivers do not need to explicitly set this field. * m_type_ident is the string identifying which MAC type plugin the driver needs to use. For Ethernet, this would be set to MAC_PLUGIN_IDENT_ETHER (as defined in PSARC/2006/248.) * m_driver is set to the driver's instance private data. This will be passed as an argument to all driver callbacks. * m_dip is the device's devinfo pointer. * m_instance is set to 0 unless the driver wishes to associate a MAC instance number with this MAC that is different from ddi_get_instance(m_dip). This is used by drivers such as "aggr" that have one devinfo pointer, but register multiple MAC's. In that case, it can register multiple MACs, each with the same m_dip, but each having a unique instance number. * m_src_addr is the unicast address of the MAC at the time mac_register() is called. * m_dst_addr is the destination address of the MAC at the time mac_register() is called. This field is meant to be used by MACs that have fixed destinations. It is thus optional and may be set to NULL. * m_callbacks defines the list of driver entry points or callbacks that GLDv3 will use. The structure of mac_callbacks_t and the definition of each callback is described in section 2.2. * m_min_sdu is set to the minimum payload size that can be conveyed by the media. * m_max_sdu is set to the maximum payload size that can be conveyed by the media. * m_data is an optional field (may be set to NULL if the plugin requires no data to function) and is used to pass state information to the MAC type plugin in use by the device. The structure of the data (if any) is defined by the plugin's documentation, and the validity of the registered data is verified by the plugin itself. If the data is invalid, mac_register() will fail. This data is copied by GLDv3, so no reference to data pointed to by m_pdata is kept by the framework. If this is set to NULL, then m_pdata_size must be set to 0. If this field is non-NULL and the requested plugin does not support MAC plugin data, then mac_register() will fail. * m_pdata_size is the size of the data pointed to by m_pdata. This allows the GLDv3 framework to copy the data. If m_pdata is NULL (no plugin data is supplied), then this must be set to 0. 2.2 mac_callbacks_t ------------------- Drivers use this structure in mac_register_t to enumerate the set of driver callbacks that GLDv3 will use. The first argument to all callbacks is a pointer to the m_driver field of mac_register_t as passed in through mac_register(). The mac_callbacks_t structure is: typedef struct mac_callbacks_s { uint_t mc_callbacks; mac_getstat_t mc_getstat; /* Get the value of a statistic */ mac_start_t mc_start; /* Start the device */ mac_stop_t mc_stop; /* Stop the device */ mac_setpromisc_t mc_setpromisc; /* Enable or disable promiscuous mode */ mac_multicst_t mc_multicst; /* Enable or disable a multicast addr */ mac_unicst_t mc_unicst; /* Set the unicast MAC address */ mac_tx_t mc_tx; /* Transmit a packet */ mac_resources_t mc_resources; /* Get the device resources */ mac_ioctl_t mc_ioctl; /* Process an unknown ioctl */ mac_getcapab_t mc_getcapab; /* Get capability information */ } mac_callbacks_t; mc_callbacks is a flags field that drivers use to denote which _optional_ callbacks are set in the structure. The last two callbacks defined in this structure are currently optional (mc_resources, mc_ioctl, and mc_capab_get), and thus the only three possible flags are: MC_RESOURCES MC_IOCTL MC_GETCAPAB Drivers that do not define mc_resources, mc_ioctl, nor mc_getcapab set mc_callbacks to 0. This flags field allows future additions to this structure to not affect existing binaries, as existing binaries will not set those future flags associated with new callbacks. As such any additions to this structure _must_ be accompanied by an associated mc_callbacks flag. In the previous GLDv3 model, callback functions (prefixed with "m_") were set directly in mac_t. These callbacks map to the new mac_callbacks_t callbacks as follows: m_stat -> mc_getstat m_start -> mc_start m_stop -> mc_stop m_promisc -> mc_setpromisc m_multicst -> mc_multicst m_unicst -> mc_unicst m_resources -> mc_resources m_ioctl -> mc_ioctl Except for mc_getstat and the new mc_getcapab (discussed below), the semantics and signature of the callbacks in mac_callbacks_t are identical to those in the previous model as set in mac_t. 2.2.1 mc_getstat ---------------- typedef int (*mac_getstat_t)(void *arg, uint_t stat, uint64_t *val); This entry point is called to retrieve a value for a statistic. There are two possible sets of statistics. One is the set of generic MAC statistics defined in the mac_driver_stat enumeration in . The other set of statistics is defined by the MAC type plugin in use by the driver. Some plugins may define no statistics. The Ethernet plugin described in PSARC/2006/248 does define statistics in , in the ether_stat enumeration. The stat argument is one of these statistics. The function must either return 0 and set the statistic's value in the "val" argument upon success, or return a non-zero errno upon failure. For example, ENOTSUP would be an acceptable return value if the statistic passed in was not supported by the driver. Note that this callback replaces what was the m_stat callback in the previous model. That model had binary compatibility problems described in bug 6226635 ("MAC stats interface could cause problems with binary compatibility".) This new callback fixes those binary compatibility problems. 2.2.2 mc_getcapab ----------------- typedef boolean_t (*mac_getcapab_t)(void *arg, uint32_t capab, void *data); This optional entry point is used to obtain the MAC's capabilities and associated data from the driver. Capabilities are defined by the GLDv3 framework, as is the format of their associated data. The requested capability is passed in as the second argument, and the function is expected to return B_TRUE if the device supports that capability, or B_FALSE if it does not. If it returns B_TRUE and the capability requires associated data, the function is expected to fill in the data as stated in the capability's documentation. In the previous model, capabilities of devices were communicated to GLDv3 as fields of the mac_info_t structure, which was embedded in the mac_t used in mac_register(). This method caused problems with binary compatibility, as no new capabilities could be defined in mac_info_t without affecting the alignment of the rest of the fields in the mac_t. This new capability mechanism addresses this binary compatibility problem. There are currently only two capabilities defined: * MAC_CAPAB_HCKSUM This is the capability of the device to perform TCP/IP checksum offload. The data points to a uint32_t which corresponds to the transmit flags associated with the capability. The driver must set these flags to to represent the offload capability. The flags are defined in , and are: HCKSUM_ENABLE HCKSUM_INET_PARTIAL HCKSUM_INET_FULL_V4 HCKSUM_INET_FULL_V6 HCKSUM_IPHDRCKSUM These flags and their semantics were introduced in PSARC/2004/106 and 2003/264. This capability replaces the mi_hcksum field in the mac_info_t structure used in the previous mac_register() model. * MAC_CAPAB_POLL This capability has no associated data. The driver simply returns B_TRUE if it supports GLDv3 polling, or B_FALSE if it does not. This capability replaces the mi_poll field in the mac_info_t structure used in the previous mac_register() model. 3 New Driver Interfaces ======================= The following two driver interfaces are introduced by this case. 3.1 mac_pdata_update -------------------- void mac_pdata_update(mac_handle_t mh, void *pdata, size_t datasize); MAC-Type plugins may require or simply optionally use MAC plugin data in order to perform their functions. This data is registered by drivers by setting the m_pdata and m_pdata_size fields of the mac_register_t used in mac_register(). When drivers need to update the data due to some administrative interaction or some other event, they can use the mac_pdata_update() function. The data is copied by the GLDv3 framework and the new data is passed into the MAC-Type callbacks of the plugin in-use by the driver. Because such MAC plugin data will cause the MAC-Type plugins to alter the headers generated by the plugins, headers cached by IP fast-path need to be flush. As such, calling this function will also cause the GLDv3 mac module to generate a MAC_NOTE_FASTPATH_FLUSH notification (introduced by this case). The GLDv3 dld module will then generate a DL_NOTIFY_IND message containing DL_NOTE_FASTPATH_FLUSH to affected DLPI consumers. The DL_NOTE_FASTPATH_FLUSH mechanism was previously introduced by PSARC/2000/285 (DLPI M_DATA fastpath flush notification.) 3.2 mac_dest_update ------------------- void mac_dest_update(mac_handle_t mh, const uint8_t *addr); Because some MAC-Types may require the configuration of a destination address (IP Tunnels for example), the mac_register_t driver registration structure allows drivers to register such an address. This function allows drivers to modify the address after registration. Calling this function will cause the GLDv3 mac module to generate a MAC_NOTE_DEST notification (introduced by this case). The GLDv3 dld module will then generate a DL_NOTIFY_IND message containing DL_NOTE_PHYS_ADDR of type DL_CURR_DEST_ADDR (also introduced by this case). 3.3 Changes to Other Driver Interfaces -------------------------------------- As noted in section 2, drivers will now use an opaque mac_handle_t as the first argument to driver interfaces, as opposed to the mac_t as in the previous model. The functions affected are: void mac_rx(mac_handle_t, mac_resource_handle_t, mblk_t *); void mac_link_update(mac_handle_t, link_state_t); void mac_unicst_update(mac_handle_t, const uint8_t *); void mac_tx_update(mac_handle_t); void mac_resource_update(mac_handle_t); mac_resource_handle_t mac_resource_add(mac_handle_t, mac_resource_t *); void mac_pdata_update(mac_handle_t, void *, size_t); void mac_multicst_refresh(mac_handle_t, mac_multicst_t, void *, boolean_t); void mac_unicst_refresh(mac_handle_t, mac_unicst_t, void *); void mac_promisc_refresh(mac_handle_t, mac_setpromisc_t, void *); The semantics of these functions are unmodified by this case. 4 MAC Client Interface Changes ============================== In order to give access to some of the new functionality defined above, new MAC client interfaces must be defined. These will give the dld, dls and aggr modules (the only three existing consumers of the MAC client interfaces) access to the new functionality. In addition, modifications to existing client interfaces need to be made to accommodate driver interface changes. 4.1 New MAC Client Interfaces ----------------------------- The following client interfaces are being introduced by this case. 4.1.1 mac_capab_get ------------------- boolean_t mac_capab_get(mac_handle_t mh, uint32_t cap, void *cap_data); This function is called by a client that wishes to obtain MAC capabilities from the driver. The set of capabilities is discussed in the context of the mc_getcapab driver callback in section 2.2.2. This functional interface replaces the previous use of the mac_info_t as a repository of capability state. 4.1.2 mac_dest_get ------------------ void mac_dest_get(mac_handle_t mh, uint8_t *dest_addr); This function is analogous to the mac_unicst_get() function already defined, but it instead obtains the current destination MAC address. 4.2 Modifications to Existing MAC Client Interfaces --------------------------------------------------- The following MAC client interface is being modified by this case: 4.2.1 mac_stat_get ------------------ uint64_t mac_stat_get(mac_handle_t mh, uint_t stat); The modified mac_stat_get() interface takes a uint_t as a second argument instead of a "enum mac_stat". The reason for this change is that prior to this case, all statistics were defined in in "enum mac_stat". This case introduces plugin-defined statistics that are defined in plugin-specific header files. Therefore, the statistics that can be requested through the mac_stat_get() interface cannot be confined to a single enum type. 5 Interface Table ================= _____________________________________________________________________________ | Interfaces Exported | |_________________________|_______________________|_________________________| | Interface | Classification | Comments | |_________________________|_______________________|_________________________| | mac_alloc() | Consolidation Private | | | mac_free() | Consolidation Private | | | mac_register() | Consolidation Private | (modified) | | mac_unregister() | Consolidation Private | (modified) | | mac_rx() | Consolidation Private | (modified) | | mac_link_update() | Consolidation Private | (modified) | | mac_unicst_update() | Consolidation Private | (modified) | | mac_tx_update() | Consolidation Private | (modified) | | mac_resource_update() | Consolidation Private | (modified) | | mac_resource_add() | Consolidation Private | (modified) | | mac_multicst_refresh() | Consolidation Private | (modified) | | mac_unicst_refresh() | Consolidation Private | (modified) | | mac_promisc_refresh() | Consolidation Private | (modified) | | mac_pdata_update() | Consolidation Private | | | mac_dest_update() | Consolidation Private | | | | | | | MC_RESOURCES | Consolidation Private | | | MC_IOCTL | Consolidation Private | | | MC_GETCAPAB | Consolidation Private | | | MAC_VERSION | Consolidation Private | | | MAC_NOTE_FASTPATH_FLUSH | Consolidation Private | | | MAC_NOTE_DEST | Consolidation Private | | | | | | | mac_register_t | Consolidation Private | | | mac_callbacks_t | Consolidation Private | | | | | | | DL_CURR_DEST_ADDR | Evolving | | |_________________________|_______________________|_________________________|Nemo MAC-Type Plugin Architecture ================================= release binding: patch 1 Introduction ============== This fast-track case is part of the Clearview umbrella case (PSARC/2005/132). It modifies and makes additions to the interfaces defined in PSARC/2004/571 (Nemo - a.k.a. GLD v3). The justification for this work and its relationship to the rest of the Clearview project is discussed in that case. To allow GLDv3 to support MAC layers other than Ethernet, a new plugin mechanism will be introduced. MAC-type plugins will be kernel modules that register with the GLDv3 mac module. MAC drivers will then be required to request the use of a particular plugin to handle the operations specific to its MAC type. The main benefits of this plugin architecture are: * To remove MAC type specific code from the GLDv3 framework. * To allow support for new MAC types to be added at any time without recompiling the GLDv3 framework. * To not burden driver developers with needing to implement boilerplate code that is MAC type specific but not specific to their particular driver. 2 MAC-type Plugin Registration =============================== MAC Type plugins will interact with the GLDv3 mac module using the following four functions: mactype_register_t *mactype_alloc(uint_t mactype_version); int mactype_register(mactype_register_t *); void mactype_free(mactype_register_t *); int mactype_unregister(const char *); When a plugin module loads, its _init() routine is invoked. At that moment, it is expected to register with the GLDv3 framework by calling mactype_register(). First, it will need to allocate a mactype_register_t data-structure to be used as the argument to mactype_register by calling mactype_alloc(). This allocation routine shields plugins from future additions to the mactype_register_t structure, thus preserving the binary compatibility of the interface. The sole argument to mactype_alloc() must be MACTYPE_VERSION (defined in ). This allows mactype_alloc() to verify if the plugin was compiled against an compatible version of the MAC-Type framework. A version mismatch will result in mactype_alloc() returning NULL, and the plugin will not be allowed to register. After having registered using mactype_register(), the mactype_register_t used to register must be freed using mactype_free(). When a plugin module is unloaded, its _fini() routine is invoked, and it is expected to unregister with the GLDv3 framework by calling mactype_unregister(). If mactype_unregister() fails by returning a non-zero error code, the plugin must not continue with mod_remove() as drivers may still be using the plugin. In that case, the plugin must return from _fini() using the error code returned by mactype_unregister(). mactype_register_t has the following structure: typedef struct mactype_register_s { uint_t mtr_version; const char *mtr_ident; mactype_ops_t *mtr_ops; uint_t mtr_mactype; uint_t mtr_addrlen; uint8_t *mtr_brdcst_addr; const char *mtr_statname; mac_stat_info_t *mtr_stats; size_t mtr_statcount; } mactype_register_t; The fields are: * mtr_version: Automatically set by mactype_alloc(). This allows mactype_register() to know which version of the MAC-Type framework the plugin was compiled against. * mtr_ident: A NULL terminated string identifying the plugin. MAC drivers will bind to a particular plugin by using this string upon registering with mac_register() (this mechanism is described in the dependent case PSARC/2006/249.) This is also the string that plugins must use to unregister when calling mactype_unregister(). * mtr_ops: A structure containing plugin callback pointers. The structure and list of defined callbacks are defined in section 3. These callbacks are the meat of the plugins. They are what GLDv3 uses to execute the MAC-Type specific functionality. * mtr_mactype: The DLPI MAC type implemented by the plugin as defined in (DL_ETHER for example). * mtr_addrlen: The length of MAC addresses for the given MAC type. * mtr_brdcst_addr: If non-NULL, this points to the broadcast address for the media. Its size must be mtr_addrlen. The address is copied by the API. * mtr_statname: The name associated with the kstats defined by the plugin. * mtr_stats: An array of mac_stat_info_t structures defining the set of statistics for the plugin. Drivers that use a given plugin are responsible for implementing the defined statistics. When MAC drivers register, the GLDv3 framework will define kstats for the MAC in accordance with the list of statistics defined by the plugin. When a request is made for a given kstat, the GLDv3 framework calls into the driver to obtain that statistic's value. The dependent case PSARC/2006/249 contains more details about how GLDv3 and drivers will handle statistics in the description of the mc_getstat driver callback. There is one strict requirement that the GLDv3 framework poses on MAC type plugins regarding statistics; All statistics defined by plugins must have a minimum value of MACTYPE_STAT_MIN. This ensures that statistics defined by plugins do not clash with generic statistics defined by the GLDv3 framework. For an example, see the Ethernet plugin described in section 5. * mtr_statcount: The number of mac_stat_info_t array elements in mtr_stats. 3 Plugin Operations =================== When registering with mactype_register(), plugins supply a set of callbacks as the mtr_ops field of the mactype_register_t. The mtr_ops field has the following structure: typedef struct mactype_ops_s { uint_t mtops_ops; mtops_addr_verify_t mtops_unicst_verify; mtops_addr_verify_t mtops_multicst_verify; mtops_sap_verify_t mtops_sap_verify; mtops_header_t mtops_header; mtops_header_info_t mtops_header_info; mtops_pdata_verify_t mtops_pdata_verify; mtops_header_modify_t mtops_header_cook; mtops_header_modify_t mtops_header_uncook; } mactype_ops_t; The mtops_ops field is a set of flags defining which optional operations are defined by the plugin. This allows the framework to define additional optional operations without having to recompile plugins, thus maintaining backward compatibility with older binary plugins. The only optional operations currently defined are mtops_pdata_verify, mtops_header_cook, and mtops_header_uncook. The flags currently defined are thus: #define MTOPS_PDATA_VERIFY 0x001 #define MTOPS_HEADER_COOK 0x002 #define MTOPS_HEADER_UNCOOK 0x004 Each plugin operation function has as one of its arguments a pointer to optional (may be NULL) MAC plugin data that the plugin may use. Plugins may require such data from drivers, and if so, must define the format of the data in its documentation and must also provide the mtops_pdata_verify operation. Each driver may then register such data in its mac_register_t when issuing mac_register(), and may update its data using mac_pdata_update(). This is discussed in the dependent case PSARC/2006/249. The following sections describe each plugin operation. 3.1 mtops_unicst_verify ----------------------- This operation verifies that a given address is a valid unicast address for the MAC type implemented by the plugin. The operation has the following type: typedef int (*mtops_addr_verify_t)(const void *addr, void *pdata); The operation must either return 0 if the given address is a valid unicast address, or a non-zero errno. 3.2 mtops_multicst_verify ------------------------- This operation verifies that a given address is a valid multicast address for the MAC type implemented by the plugin. The operation has the same type as mtops_unicst_verify. The operation must either return 0 if the given address is a valid multicast address, or a non-zero errno. For example, if multicast is supported by the MAC type but the address has an invalid format, EINVAL would be an acceptable return value. If multicast is not supported at all by the MAC type, ENOTSUP would be an acceptable return value. 3.3 mtops_sap_verify -------------------- This operation verifies that a given DLPI SAP is valid for the MAC type implemented by the plugin. The operation has the following type: typedef boolean_t (*mtops_sap_verify_t)(uint32_t sap, uint32_t *bind_sap, void *pdata); The sap argument is the one being verified. The function returns B_TRUE if the sap is valid, or B_FALSE if it is nor. The operation also optionally sets bind_sap (if non_NULL) to the value to which GLDv3 should bind DLPI consumers. This is used by the Ethernet plugin (described in section 5) to bind all LLC SAPs to bind to the same value, 0. 3.4 mtops_header ---------------- This operation allocates and constructs a MAC header. It has the following type: typedef mblk_t *(*mtops_header_t)(const void *saddr, const void *daddr, uint32_t sap, void *pdata, size_t extra_len); The operation allocates an mblk_t and fills in its contents with a MAC header using the source address "saddr", the destination address "daddr", the given sap, and optional MAC plugin data. The extra_len argument tells the operation how much extra space to allocate following the end of the header. For example, the dls module uses this extra length feature to pre-allocate space for VLAN tag information. The operation returns a valid pointer to the allocated mblk_t upon success, or NULL upon failure. The b_wptr field of the returned mblk_t points to the end of the header, leaving any potential extra space after the b_wptr. 3.5 mtops_header_info --------------------- This operation takes an mblk_t whose b_rptr points to the beginning of a MAC header, and returns information about that header. typedef int (*mtops_header_info_t)(mblk_t *mp, void *pdata, mac_header_info_t *mhip); The function returns 0 upon success, or a non-zero errno upon failure (if the mblk is too small to contain a valid header, for example). The operation returns the needed information by filling in the mac_header_info_t structure pointed to by the third argument. typedef struct mac_header_info_s { size_t mhi_hdrsize; size_t mhi_pktsize; const uint8_t *mhi_daddr; const uint8_t *mhi_saddr; uint32_t mhi_origsap; uint32_t mhi_bindsap; mac_addrtype_t mhi_dsttype; } mac_header_info_t; * mhi_hdrsize is set to the size of the header. * mhi_pktsize is set to the size of the entire packet contained in the mblk (including the header). The special value 0 means that the packet is of size MBLKL(mp). This special value exists because most headers don't have packet size information, and thus the only logical size if MBLKL(mp). * mhi_daddr and mhi_saddr point to the destination and source addresses. These are pointers to the actual addresses in the header, not copies. * mhi_origsap is the value of the SAP in the header. * mhi_bindsap is the value to which DLPI consumers interested in this SAP will be bound to. This is the same value that would be returned if mhi_origsap were passed into the mtops_sap_verify operation. * mhi_dsttype describes the type of the destination address, which can be set to one of: MAC_ADDRTYPE_UNICAST MAC_ADDRTYPE_MULTICAST MAC_ADDRTYPE_BROADCAST The mac_header_info_t structure replaces what was the dls_header_info_t in PSARC/2004/571. 3.6 mtops_pdata_verify ---------------------- This operation verifies that the MAC plugin data being registered by a driver is valid. Its type is: typedef boolean_t (*mtops_pdata_verify_t)(void *pdata); This optional operation must be provided if the plugin supports MAC plugin data. The function returns B_TRUE if the data is valid, or B_FALSE if it isn't. The validity of MAC plugin data is a plugin specific property, and the format of valid MAC plugin data should be documented in each plugin's documentation. This is called when drivers register MAC plugin data via mac_register(), and also when drivers update MAC plugin data via mac_pdata_update(). Both of these functions are described in PSARC/2006/249. 3.7 mtops_header_cook --------------------- This operation modifies the given MAC header as transmitted by RAW DLPI consumers. Its type is: typedef mblk_t *(*mtops_header_modify_t)(mblk_t *raw_header, void *pdata); Solaris DLPI has a special raw mode enabled using the DLIOCRAW ioctl. In this mode, DLPI consumers can send packets that include the desired link-layer header, and can receive packets that include the link-layer header. One example of an application that uses this mode is snoop(1M), which requires the ability to receive link-layer headers in order to properly display them to the user. This operation takes a packet as sent down to the GLDv3 framework from a raw DLPI consumer (raw_header), and "cooks" the header for transmission to the underlying driver. The mblk's DB_REF() count is guaranteed to be 1 by the GLDv3 framework. Upon failure, NULL is returned and the mblk passed in remains unmodified. Upon success, the modified mblk is returned. This is used, for example, by plugins that wish to give raw DLPI consumers the illusion that the device implements a MAC type different than what is actually being implemented by the driver. Examples of this are WiFi technologies that have very complex MAC layer protocols that wish to be accessed and observed as regular Ethernet by raw consumers. In fact, this project has worked closely with the WiFi team, which has developed a WiFi plugin that implements this operation (along with the associated mtops_header_uncook described below.) The WiFi MAC-Type plugin itself is not part of this case, and will be submitted separately. 3.8 mtops_header_uncook ----------------------- This operation does the opposite of mtops_header_cook. Its type is also the same. It takes a packet as received by the driver and "uncooks" the header such that the packet can be passed up to raw DLPI consumers. This operation can make the same DB_REF() assumption as mtops_header_cook(), and also has the same success and error semantics. 4 MAC Client Functions to Access Plugin Functionality ===================================================== The MAC-Type plugins register with the GLDv3 mac module, and therefore the mac module has direct access to the plugin operations described in the previous section. The functionality implemented by these operations needs to be accessed by other pieces of the GLDv3 stack, namely the MAC clients dld, dls and aggr. As such, new MAC client interfaces are defined here to give access to the new plugin functionality. Note that there are no new interfaces defined to directly access the mtops_unicst_verify and mtops_multicst_verify operations, as these operations are called from the existing MAC client interfaces, mac_unicst_set() and mac_multicst_add(). 4.1 mac_sap_verify ------------------ boolean_t mac_sap_verify(mac_handle_t mh, uint32_t sap, uint32_t *bind_sap); This function is the MAC client interface for the mtops_sap_verify MAC-Type plugin callback described in section 3.3. 4.2 mac_header -------------- mblk_t *mac_header(mac_handle_t mh, const uint8_t *dst, uint32_t sap, size_t extralen); This function is the MAC client interface for the mtops_header MAC-Type plugin callback described in section 3.4. 4.3 mac_header_info ------------------- void mac_header_info(mac_handle_t mh, mblk_t *mp, mac_header_info_t *mhip); This is the MAC client interface for the mtops_header_info MAC-Type plugin callback described in section 3.5. 4.4 mac_header_cook ------------------- mblk_t *mac_header_cook(mac_handle_t mh, mblk_t *mp); This is the MAC client interface for the mtops_header_cook MAC-Type plugin callback described in section 3.7. The mp argument must point to the beginning of the header. If an error occurs, mac_header_cook() returns NULL, and mp is unmodified. If mac_header_cook() is successful, it will return a pointer to the modified mblk. This pointer may be different from the original, so it is imperative that callers no longer use the mp pointer they passed in as the second argument, as that mp may have been freed by the interface (if DB_REF(mp) was > 1 for example). 4.5 mac_header_uncook --------------------- mblk_t *mac_header_uncook(mac_handle_t mh, mblk_t *mp); This is the MAC client interface for the mtops_header_uncook MAC-Type plugin callback described in section 3.8. It has the same calling semantics as mac_header_cook described above, except that it does the opposite operation on the header. 5 Loading Plugin Kernel Modules =============================== When a driver requests the use of a given plugin, the mac module attempts to load the plugin from /kernel/mac (a new directory introduced by this case) using modload(). The modload() is what drives the plugin's _init() routine to be called, and the plugin to register via mactype_register(). As a result, all MAC-Type plugins present and future _must_ install in /kernel/mac. 6 Ethernet MAC Type Plugin ========================== One plugin that will be delivered as part of this case will be a DL_ETHER Ethernet plugin. It will implement all plugin operations except for mtops_header_cook and mtops_header_uncook, which it has no need to implement. The plugin kernel module will install as /kernel/mac/ether. A header file will contain the necessary information for drivers to use the plugin, namely a MAC_PLUGIN_IDENT_ETHER macro used to identify the plugin during mac_register(), and the list of statistics defined by the plugin. The statistics are: enum ether_stat { /* RFC 1643 stats */ ETHER_STAT_ALIGN_ERRORS = MACTYPE_STAT_MIN, ETHER_STAT_FCS_ERRORS, ETHER_STAT_FIRST_COLLISIONS, ETHER_STAT_MULTI_COLLISIONS, ETHER_STAT_SQE_ERRORS, ETHER_STAT_DEFER_XMTS, ETHER_STAT_TX_LATE_COLLISIONS, ETHER_STAT_EX_COLLISIONS, ETHER_STAT_MACXMT_ERRORS, ETHER_STAT_CARRIER_ERRORS, ETHER_STAT_TOOLONG_ERRORS, ETHER_STAT_MACRCV_ERRORS, /* MII/GMII stats */ ETHER_STAT_XCVR_ADDR, ETHER_STAT_XCVR_ID, ETHER_STAT_XCVR_INUSE, ETHER_STAT_CAP_1000FDX, ETHER_STAT_CAP_1000HDX, ETHER_STAT_CAP_100FDX, ETHER_STAT_CAP_100HDX, ETHER_STAT_CAP_100FDX, ETHER_STAT_CAP_100HDX, ETHER_STAT_CAP_10FDX, ETHER_STAT_CAP_10HDX, ETHER_STAT_CAP_ASMPAUSE, ETHER_STAT_CAP_PAUSE, ETHER_STAT_CAP_AUTONEG, ETHER_STAT_ADV_CAP_1000FDX, ETHER_STAT_ADV_CAP_1000HDX, ETHER_STAT_ADV_CAP_100FDX, ETHER_STAT_ADV_CAP_100HDX, ETHER_STAT_ADV_CAP_10FDX, ETHER_STAT_ADV_CAP_10HDX, ETHER_STAT_ADV_CAP_ASMPAUSE, ETHER_STAT_ADV_CAP_PAUSE, ETHER_STAT_ADV_CAP_AUTONEG, ETHER_STAT_LP_CAP_1000FDX, ETHER_STAT_LP_CAP_1000HDX, ETHER_STAT_LP_CAP_100FDX, ETHER_STAT_LP_CAP_100HDX, ETHER_STAT_LP_CAP_10FDX, ETHER_STAT_LP_CAP_10HDX, ETHER_STAT_LP_CAP_ASMPAUSE, ETHER_STAT_LP_CAP_10HDX, ETHER_STAT_LP_CAP_ASMPAUSE, ETHER_STAT_LP_CAP_PAUSE, ETHER_STAT_LP_CAP_AUTONEG, ETHER_STAT_LINK_ASMPAUSE, ETHER_STAT_LINK_PAUSE, ETHER_STAT_LINK_AUTONEG, ETHER_STAT_LINK_DUPLEX }; Drivers using the Ethernet plugin will receive requests for these statistics via the mc_getstat driver callback described in PSARC/2006/249. 7 Interface Table ================= _____________________________________________________________________________ | Interfaces Exported | |________________________|_______________________|__________________________| | Interface | Classification | Comments | |________________________|_______________________|__________________________| | mactype_alloc() | Consolidation Private | | | mactype_free() | Consolidation Private | | | mactype_register() | Consolidation Private | | | mactype_unregister() | Consolidation Private | | | | | | | MTOPS_HEADER_COOK | Consolidation Private | | | MTOPS_HEADER_UNCOOK | Consolidation Private | | | MAC_ADDRTYPE_UNICAST | Consolidation Private | | | MAC_ADDRTYPE_MULTICAST | Consolidation Private | | | MAC_ADDRTYPE_BROADCAST | Consolidation Private | | | MACTYPE_STAT_MIN | Consolidation Private | | | | | | | mactype_register_t | Consolidation Private | | | mactype_ops_t | Consolidation Private | | | mac_header_info_t | Consolidation Private | | | | | | | mac_sap_verify() | Consolidation Private | | | mac_header() | Consolidation Private | | | mac_header_info() | Consolidation Private | | | mac_header_cook() | Consolidation Private | | | mac_header_uncook() | Consolidation Private | | | | | | | MAC_PLUGIN_IDENT_ETHER | Consolidation Private | | | enum ether_stat | Consolidation Private | | |________________________|_______________________|__________________________| From sacadmin Thu Apr 13 14:24:33 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3DLOXIQ006745 for ; Thu, 13 Apr 2006 14:24:33 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXO00E01JG0NQ@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Thu, 13 Apr 2006 17:24:32 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXO000XIJGWNY@bur-mail2.east.sun.com>; Thu, 13 Apr 2006 17:24:32 -0400 (EDT) Date: Thu, 13 Apr 2006 17:24:32 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <443EBE18.4040409@sun.com> To: Sebastien Roy Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <443EC190.8040808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) References: <443EBE18.4040409@sun.com> Status: RO Content-Length: 194 The contents of 2006/248 appear to have been mistakenly included at the end of the message introducing this case. Please ignore the duplicate 2006/248 text that appears after section 5. -Seb From sacadmin Thu Apr 13 14:35:00 2006 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3DLZ0IQ007184 for ; Thu, 13 Apr 2006 14:35:00 -0700 (PDT) Received: from grimmy (grimmy.SFBay.Sun.COM [129.146.108.114]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3DLYx7d025189; Thu, 13 Apr 2006 14:34:59 -0700 (PDT) Date: Thu, 13 Apr 2006 14:34:20 -0700 (PDT) From: Randy Fishel X-X-Sender: randyf@grimmy To: Sebastien Roy cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: <443EBE18.4040409@sun.com> Message-ID: References: <443EBE18.4040409@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Content-Length: 3125 Glad to see this! On Thu, 13 Apr 2006, Sebastien Roy wrote: > 5 Interface Table > ================= > > _____________________________________________________________________________ > | Interfaces Exported | > |_________________________|_______________________|_________________________| > | Interface | Classification | Comments | > |_________________________|_______________________|_________________________| > | mac_alloc() | Consolidation Private | | > | mac_free() | Consolidation Private | | > | mac_register() | Consolidation Private | (modified) | > | mac_unregister() | Consolidation Private | (modified) | > | mac_rx() | Consolidation Private | (modified) | > | mac_link_update() | Consolidation Private | (modified) | > | mac_unicst_update() | Consolidation Private | (modified) | > | mac_tx_update() | Consolidation Private | (modified) | > | mac_resource_update() | Consolidation Private | (modified) | > | mac_resource_add() | Consolidation Private | (modified) | > | mac_multicst_refresh() | Consolidation Private | (modified) | > | mac_unicst_refresh() | Consolidation Private | (modified) | > | mac_promisc_refresh() | Consolidation Private | (modified) | > | mac_pdata_update() | Consolidation Private | | > | mac_dest_update() | Consolidation Private | | > | | | | > | MC_RESOURCES | Consolidation Private | | > | MC_IOCTL | Consolidation Private | | > | MC_GETCAPAB | Consolidation Private | | > | MAC_VERSION | Consolidation Private | | > | MAC_NOTE_FASTPATH_FLUSH | Consolidation Private | | > | MAC_NOTE_DEST | Consolidation Private | | > | | | | > | mac_register_t | Consolidation Private | | > | mac_callbacks_t | Consolidation Private | | > | | | | > | DL_CURR_DEST_ADDR | Evolving | | > |_________________________|_______________________|_________________________|Nemo As we have been telling just about anyone who is doing NIC drivers that Nemo is the way to go, is it possibly time to promote these interfaces to something other than "Private"? If we feel confident that these interfaces won't change incompatibly in this release, maybe we can consider them "Evolving" (or at least "Unstable", but otherwise committed)? ---- Randy From sacadmin Thu Apr 13 14:55:05 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3DLt4IQ007971 for ; Thu, 13 Apr 2006 14:55:04 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXO00301KPDDD@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Thu, 13 Apr 2006 17:55:04 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXO0008CKVSNY@bur-mail2.east.sun.com>; Thu, 13 Apr 2006 17:55:04 -0400 (EDT) Date: Thu, 13 Apr 2006 17:55:04 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: To: Randy Fishel Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, gld-iteam@sun.com Message-id: <443EC8B8.8050401@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) References: <443EBE18.4040409@sun.com> Status: RO Content-Length: 1002 (I've added gld-iteam to the Cc list) Randy Fishel wrote: > As we have been telling just about anyone who is doing NIC drivers > that Nemo is the way to go, is it possibly time to promote these > interfaces to something other than "Private"? It is the goal of the Nemo team to promote these interfaces eventually, and that this work is a pre-requisite for that to happen. > > If we feel confident that these interfaces won't change incompatibly > in this release, maybe we can consider them "Evolving" (or at least > "Unstable", but otherwise committed)? The complete set of Nemo driver interfaces that would need to be promoted is a superset of the interfaces being modified by these two fast-tracks. As such, these cases are not sufficient as written to allow for the promotion of the complete set of driver interfaces. Another case would be needed to enumerate the complete set of driver interfaces, their new stability level, along with a comprehensive set of documentation. -Seb From sacadmin Tue Apr 18 01:05:26 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3I85PIQ013870 for ; Tue, 18 Apr 2006 01:05:25 -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.12.10+Sun/8.12.9) with ESMTP id k3I85IFV012811 for ; Tue, 18 Apr 2006 16:05:19 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IXW00601RSC8J00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 18 Apr 2006 16:05:18 +0800 (SGT) Received: from [129.158.87.138] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXW00D4ARST36R0@mail-apac.sun.com>; Tue, 18 Apr 2006 16:05:18 +0800 (SGT) Date: Tue, 18 Apr 2006 01:03:44 -0700 From: Darren Reed Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <443EBE18.4040409@sun.com> Sender: Darren.Reed@Sun.COM To: Sebastien Roy Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <44449D60.6090903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <443EBE18.4040409@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 3060 Sebastien Roy wrote: > ... > 2 Changes to mac_register() > =========================== > > The cornerstone of the GLDv3 MAC driver interface is the > mac_register() > function, which is used by GLDv3 drivers to register MAC devices. In > order to create a binary compatible interface, driver registration > will be > modified such that drivers will use the following four functions: > > mac_register_t *mac_alloc(uint_t mac_version); > int mac_register(mac_register_t *, mac_handle_t *); > void mac_free(mac_register_t *); > int mac_unregister(mac_handle_t); > > In order to register, drivers will first allocate a mac_register_t > structure using mac_alloc(). The sole argument to mac_alloc() > _must_ be > MAC_VERSION (defined in ). Passing in MAC_VERSION allows > mac_alloc() to verify if the driver was compiled against a version > of the > GLDv3 framework which is compatible with what is running on the > system. > In the case of an incompatible version, mac_alloc() fails and returns > NULL. If the version is compatible, it will allocate a mac_register_t > structure and return a pointer to it. The m_version field of the > returned > structure will have been automatically set to the requested version by > mac_alloc(). > > Drivers will then fill in the rest of the mac_register_t structure > with > the required information and pass it into mac_register(), which will > return an opaque MAC handle for use in all other driver interface > functions. The registration structure can be immediately freed after > registration using the mac_free() function. When the device > detaches and > needs to unregister, it passes this handle into mac_unregister(). > > The benefit of this model is that drivers are shielded from knowing > the > real size of the mac_register_t structure. The GLDv3 framework can > grow > to include more optional information in mac_register_t (thus > returning a > larger structure in mac_alloc()), and drivers will only fill in the > parts > of the structure that they were compiled to know about, thus > preserving > binary compatibility. > ... I appreciate that you're trying to improve the architecture of this interface here, but is this the right path to take? If I look across other 'alloc' functions that are part of stable interfaces in Solaris today, none of them take a version number. If you were to provide a larger set of functions, set/get ones for each of the fields in mac_register_t, would there any need to specify a version number as is being done here? What would be required to support mac_register_t being a 'void *'? Or is doing that of no benefit here in paving the way towards a stable API? Darren p.s Apologies for not bringing this up on networking-discuss, but these questions were brewing in my mind last week until I got into the customer-visit swing for a couple of days and then it was Easter here (4 day weekend.) From sacadmin Tue Apr 18 07:02:21 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IE2LIQ022167 for ; Tue, 18 Apr 2006 07:02:21 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXX00J018AIWU@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 18 Apr 2006 10:02:21 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IXX00I988BWT2@bur-mail2.east.sun.com>; Tue, 18 Apr 2006 10:02:21 -0400 (EDT) Date: Tue, 18 Apr 2006 10:02:02 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <44449D60.6090903@sun.com> To: Darren Reed Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <1145368922.3545.121.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> Status: RO Content-Length: 1436 On Tue, 2006-04-18 at 01:03 -0700, Darren Reed wrote: > I appreciate that you're trying to improve the architecture of > this interface here, but is this the right path to take? > > If I look across other 'alloc' functions that are part of stable > interfaces in Solaris today, none of them take a version number. Similarity with memory allocation functions was never a requirement nor a goal. This function retrieves a registration structure that can be used to register. The idea behind using a version number is that drivers that were compiled against an incompatible version of the framework can be gracefully rejected from allocating a registration structure and thus from continuing to interact with the framework. Without this, a driver could be passing in subtly incompatible data to the framework resulting in panics. > > If you were to provide a larger set of functions, set/get ones for > each of the fields in mac_register_t, would there any need to specify > a version number as is being done here? Yes, the version number is needed to prevent incompatible drivers from using the framework at all instead of causing a panic down the road. > > What would be required to support mac_register_t being a 'void *'? > > Or is doing that of no benefit here in paving the way towards a > stable API? I don't think it does no benefit, but I don't see how it addresses any architectural issues with the proposal. -Seb From sacadmin Tue Apr 18 07:45:45 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IEjiIQ022728 for ; Tue, 18 Apr 2006 07:45:44 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k3IEiKal005285; Tue, 18 Apr 2006 14:44:21 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k3IEiK37005284; Tue, 18 Apr 2006 10:44:20 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2006/249 Nemo Changes for Binary Compatibility From: Bill Sommerfeld To: Sebastien Roy Cc: Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com In-Reply-To: <1145368922.3545.121.camel@localhost> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1145371460.1345.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Tue, 18 Apr 2006 10:44:20 -0400 Status: RO Content-Length: 521 On Tue, 2006-04-18 at 10:02, Sebastien Roy wrote: > > What would be required to support mac_register_t being a 'void *'? > > > > Or is doing that of no benefit here in paving the way towards a > > stable API? > > I don't think it does no benefit, but I don't see how it addresses any > architectural issues with the proposal. Use of void * may cause harm, actually -- my understanding is that use of void * is known to create difficulty for mdb's post-mortem type inference system (::typegraph, etc.,). - Bill From sacadmin Tue Apr 18 07:58:46 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IEwkIQ023459 for ; Tue, 18 Apr 2006 07:58:46 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3IEwjWY027490; Tue, 18 Apr 2006 09:58:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3IEwjJf027489; Tue, 18 Apr 2006 09:58:45 -0500 (CDT) Date: Tue, 18 Apr 2006 09:58:45 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: Sebastien Roy , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility Message-ID: <20060418145845.GH26823@binky.Central.Sun.COM> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145371460.1345.18.camel@localhost> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1130 On Tue, Apr 18, 2006 at 10:44:20AM -0400, Bill Sommerfeld wrote: > On Tue, 2006-04-18 at 10:02, Sebastien Roy wrote: > > > What would be required to support mac_register_t being a 'void *'? > > > > > > Or is doing that of no benefit here in paving the way towards a > > > stable API? > > > > I don't think it does no benefit, but I don't see how it addresses any > > architectural issues with the proposal. > > Use of void * may cause harm, actually -- my understanding is that use > of void * is known to create difficulty for mdb's post-mortem type > inference system (::typegraph, etc.,). void * is not a good way to define opaque types as it defeats strong type checking, use pointers to incomplete structures instead: typedef struct foo *foo_t; But in kernel-land you can probably find a less heavy-handed solution (i.e., that doesn't force consumers to use accessor functions for everything of interest in that struct); just make sure that the struct's size is not part of the resulting ABI and put a version number somewhere in it, which you can do by forcing drivers to use a stable constructor interface. Nico -- From sacadmin Tue Apr 18 08:03:00 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IF30IQ023694 for ; Tue, 18 Apr 2006 08:03:00 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXX00601B1IFP@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 18 Apr 2006 11:03:00 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IXX008VAB4Z6B@bur-mail2.east.sun.com>; Tue, 18 Apr 2006 11:02:59 -0400 (EDT) Date: Tue, 18 Apr 2006 11:02:41 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <20060418145845.GH26823@binky.Central.Sun.COM> To: Nicolas Williams Cc: Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <1145372561.3545.132.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> Status: RO Content-Length: 901 On Tue, 2006-04-18 at 09:58 -0500, Nicolas Williams wrote: > > void * is not a good way to define opaque types as it defeats strong > type checking, use pointers to incomplete structures instead: > > typedef struct foo *foo_t; That's right, but I think that Darren's underlying suggestion wasn't necessarily to use "void *" specifically, but to have an opaque structure. Regardless, that approach would not further the architectural goals of this interface. > > But in kernel-land you can probably find a less heavy-handed solution > (i.e., that doesn't force consumers to use accessor functions for > everything of interest in that struct); just make sure that the struct's > size is not part of the resulting ABI and put a version number somewhere > in it, which you can do by forcing drivers to use a stable constructor > interface. I agree, and that is what is being proposed here. -Seb From sacadmin Tue Apr 18 08:11:31 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFBUIQ024015 for ; Tue, 18 Apr 2006 08:11:31 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k3IFBUqG007244; Tue, 18 Apr 2006 11:11:30 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k3IFBTt8007241; Tue, 18 Apr 2006 11:11:29 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17477.417.903939.130858@triplex.East.Sun.COM> Date: Tue, 18 Apr 2006 11:11:29 -0400 To: Nicolas Williams Cc: Bill Sommerfeld , Sebastien Roy , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: <20060418145845.GH26823@binky.Central.Sun.COM> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 524 > void * is not a good way to define opaque types as it defeats strong > type checking, use pointers to incomplete structures instead: > > typedef struct foo *foo_t; Yes -- and we already do this for mac_handle_t. However, in this case, we're not trying to define an opaque type -- indeed, it is essential to the proposal that mac_register_t *not* be opaque, since drivers fill it in. Thus, in order to ensure the drivers and the framework have the same structure definition, mac_alloc() takes a version. -- meem From sacadmin Tue Apr 18 08:12:49 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFCnIQ024049 for ; Tue, 18 Apr 2006 08:12:49 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3IFCnPR027504; Tue, 18 Apr 2006 10:12:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3IFCnFs027503; Tue, 18 Apr 2006 10:12:49 -0500 (CDT) Date: Tue, 18 Apr 2006 10:12:48 -0500 From: Nicolas Williams To: Sebastien Roy Cc: Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility Message-ID: <20060418151248.GI26823@binky.Central.Sun.COM> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145372561.3545.132.camel@localhost> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1522 On Tue, Apr 18, 2006 at 11:02:41AM -0400, Sebastien Roy wrote: > On Tue, 2006-04-18 at 09:58 -0500, Nicolas Williams wrote: > > But in kernel-land you can probably find a less heavy-handed solution > > (i.e., that doesn't force consumers to use accessor functions for > > everything of interest in that struct); just make sure that the struct's > > size is not part of the resulting ABI and put a version number somewhere > > in it, which you can do by forcing drivers to use a stable constructor > > interface. > > I agree, and that is what is being proposed here. Yes. I would only add that the current proposal seems too restrictive about versioning. In particular the m_version field of the mac_register_t should, IMO, be the version that the driver indicated support for when it called mac_alloc(), not the version of the framework (which the driver could get at by calling some mac_version() function). I appreciate that initially there would be but one supported version of the framework, but I figure that eventually there may be more than one. Also, mac_alloc() can only return NULL or a mac_register_t. How will a driver know if mac_alloc() failure was the result of version mismatch or ENOMEM? This seems important, as failure to load a driver should result in some useful diagnostic log message, but if mac_alloc() is the only component that can make this particular distinction then users will have to manually correlate log entries from it to driver load failures -- decidely not friendly. Nico -- From sacadmin Tue Apr 18 08:18:06 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFI6IQ024068 for ; Tue, 18 Apr 2006 08:18:06 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXX00F01BPV1Z@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 18 Apr 2006 11:18:06 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IXX008B4BU56B@bur-mail2.east.sun.com>; Tue, 18 Apr 2006 11:18:05 -0400 (EDT) Date: Tue, 18 Apr 2006 11:17:47 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <20060418151248.GI26823@binky.Central.Sun.COM> To: Nicolas Williams Cc: Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <1145373467.3545.138.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> Status: RO Content-Length: 2050 On Tue, 2006-04-18 at 10:12 -0500, Nicolas Williams wrote: > On Tue, Apr 18, 2006 at 11:02:41AM -0400, Sebastien Roy wrote: > > On Tue, 2006-04-18 at 09:58 -0500, Nicolas Williams wrote: > > > But in kernel-land you can probably find a less heavy-handed solution > > > (i.e., that doesn't force consumers to use accessor functions for > > > everything of interest in that struct); just make sure that the struct's > > > size is not part of the resulting ABI and put a version number somewhere > > > in it, which you can do by forcing drivers to use a stable constructor > > > interface. > > > > I agree, and that is what is being proposed here. > > Yes. I would only add that the current proposal seems too restrictive > about versioning. > > In particular the m_version field of the mac_register_t should, IMO, be > the version that the driver indicated support for when it called > mac_alloc(), not the version of the framework (which the driver could > get at by calling some mac_version() function). This is already the existing proposal. Section 2: "The m_version field of the returned structure will have been automatically set to the requested version by mac_alloc()." > > I appreciate that initially there would be but one supported version of > the framework, but I figure that eventually there may be more than one. That's true, and we've taken that into account in this proposal. > > Also, mac_alloc() can only return NULL or a mac_register_t. How will a > driver know if mac_alloc() failure was the result of version mismatch or > ENOMEM? This seems important, as failure to load a driver should result > in some useful diagnostic log message, but if mac_alloc() is the only > component that can make this particular distinction then users will have > to manually correlate log entries from it to driver load failures -- > decidely not friendly. You're right, so perhaps a pointer to an error code as an argument to mac_alloc() would be in order, and it would only be set if NULL is returned. How does that sound? -Seb From sacadmin Tue Apr 18 08:20:15 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFKEIQ024082 for ; Tue, 18 Apr 2006 08:20:14 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k3IFKE6I007294; Tue, 18 Apr 2006 11:20:14 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k3IFKENh007291; Tue, 18 Apr 2006 11:20:14 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17477.942.147396.431791@triplex.East.Sun.COM> Date: Tue, 18 Apr 2006 11:20:14 -0400 To: Sebastien Roy Cc: Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: <1145373467.3545.138.camel@localhost> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 851 > > Also, mac_alloc() can only return NULL or a mac_register_t. How will a > > driver know if mac_alloc() failure was the result of version mismatch or > > ENOMEM? This seems important, as failure to load a driver should result > > in some useful diagnostic log message, but if mac_alloc() is the only > > component that can make this particular distinction then users will have > > to manually correlate log entries from it to driver load failures -- > > decidely not friendly. > > You're right, so perhaps a pointer to an error code as an argument to > mac_alloc() would be in order, and it would only be set if NULL is > returned. How does that sound? As I recall the original proposal, mac_alloc() was supposed to be a sleeping allocation (though I don't see mention of this in the current proposal). Has this changed? -- meem From sacadmin Tue Apr 18 08:24:07 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFO6IQ024121 for ; Tue, 18 Apr 2006 08:24:07 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXX00J01C1DGU@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 18 Apr 2006 11:24:06 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IXX008XJC466B@bur-mail2.east.sun.com>; Tue, 18 Apr 2006 11:24:06 -0400 (EDT) Date: Tue, 18 Apr 2006 11:23:48 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <17477.942.147396.431791@triplex.East.Sun.COM> To: Peter Memishian Cc: Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <1145373828.3545.143.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> Status: RO Content-Length: 1166 On Tue, 2006-04-18 at 11:20 -0400, Peter Memishian wrote: > > > Also, mac_alloc() can only return NULL or a mac_register_t. How will a > > > driver know if mac_alloc() failure was the result of version mismatch or > > > ENOMEM? This seems important, as failure to load a driver should result > > > in some useful diagnostic log message, but if mac_alloc() is the only > > > component that can make this particular distinction then users will have > > > to manually correlate log entries from it to driver load failures -- > > > decidely not friendly. > > > > You're right, so perhaps a pointer to an error code as an argument to > > mac_alloc() would be in order, and it would only be set if NULL is > > returned. How does that sound? > > As I recall the original proposal, mac_alloc() was supposed to be a > sleeping allocation (though I don't see mention of this in the current > proposal). Has this changed? > No, that's still the case. The only way that mac_alloc() can currently fail is if there is a version mismatch. I guess I jumped the gun on this suggestion. In that case, Nicolas, are you satisfied with the interface as-is? -Seb From sacadmin Tue Apr 18 08:24:38 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFObIQ024133 for ; Tue, 18 Apr 2006 08:24:38 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3IFObl4027527; Tue, 18 Apr 2006 10:24:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3IFObDo027526; Tue, 18 Apr 2006 10:24:37 -0500 (CDT) Date: Tue, 18 Apr 2006 10:24:37 -0500 From: Nicolas Williams To: Sebastien Roy Cc: Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility Message-ID: <20060418152437.GK26823@binky.Central.Sun.COM> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145373467.3545.138.camel@localhost> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1992 On Tue, Apr 18, 2006 at 11:17:47AM -0400, Sebastien Roy wrote: > On Tue, 2006-04-18 at 10:12 -0500, Nicolas Williams wrote: > > In particular the m_version field of the mac_register_t should, IMO, be > > the version that the driver indicated support for when it called > > mac_alloc(), not the version of the framework (which the driver could > > get at by calling some mac_version() function). > > This is already the existing proposal. Section 2: > > "The m_version field of the returned structure will have been > automatically set to the requested version by mac_alloc()." Er, I read this part: * m_version will be set to MAC_VERSION (defined in ) by the mac_alloc() function. This allows the mac module to know what version of the MAC driver interface the driver was compiled against. Drivers do not need to explicitly set this field. which seems to conflict with the part you quote. > > Also, mac_alloc() can only return NULL or a mac_register_t. How will a > > driver know if mac_alloc() failure was the result of version mismatch or > > ENOMEM? This seems important, as failure to load a driver should result > > in some useful diagnostic log message, but if mac_alloc() is the only > > component that can make this particular distinction then users will have > > to manually correlate log entries from it to driver load failures -- > > decidely not friendly. > > You're right, so perhaps a pointer to an error code as an argument to > mac_alloc() would be in order, and it would only be set if NULL is > returned. How does that sound? I'd rather the mac_register_t be returned through a pointer and an error code be the return type for the function. But this is probably a matter of style. Also, what are the error codes, if any, returned by mac_register() and mac_unregister()? I only noticed something about what mac_unregister() returns, nothing about what mac_register() returns (but I did not read the materials that closely). Nico -- From sacadmin Tue Apr 18 08:25:12 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFPCIQ024146 for ; Tue, 18 Apr 2006 08:25:12 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3IFPBsx027534; Tue, 18 Apr 2006 10:25:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3IFPBQd027533; Tue, 18 Apr 2006 10:25:11 -0500 (CDT) Date: Tue, 18 Apr 2006 10:25:11 -0500 From: Nicolas Williams To: Sebastien Roy Cc: Peter Memishian , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility Message-ID: <20060418152511.GL26823@binky.Central.Sun.COM> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <1145373828.3545.143.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145373828.3545.143.camel@localhost> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 553 On Tue, Apr 18, 2006 at 11:23:48AM -0400, Sebastien Roy wrote: > On Tue, 2006-04-18 at 11:20 -0400, Peter Memishian wrote: > > As I recall the original proposal, mac_alloc() was supposed to be a > > sleeping allocation (though I don't see mention of this in the current > > proposal). Has this changed? > > > > No, that's still the case. The only way that mac_alloc() can currently > fail is if there is a version mismatch. I guess I jumped the gun on > this suggestion. In that case, Nicolas, are you satisfied with the > interface as-is? Sure. From sacadmin Tue Apr 18 08:35:07 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFZ7IQ024438 for ; Tue, 18 Apr 2006 08:35:07 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXX00201CK2SY@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 18 Apr 2006 11:35:06 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IXX008W6CMI6B@bur-mail2.east.sun.com>; Tue, 18 Apr 2006 11:35:06 -0400 (EDT) Date: Tue, 18 Apr 2006 11:34:47 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <20060418152437.GK26823@binky.Central.Sun.COM> To: Nicolas Williams Cc: Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <1145374487.3545.154.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <20060418152437.GK26823@binky.Central.Sun.COM> Status: RO Content-Length: 1824 On Tue, 2006-04-18 at 10:24 -0500, Nicolas Williams wrote: > On Tue, Apr 18, 2006 at 11:17:47AM -0400, Sebastien Roy wrote: > > On Tue, 2006-04-18 at 10:12 -0500, Nicolas Williams wrote: > > > In particular the m_version field of the mac_register_t should, IMO, be > > > the version that the driver indicated support for when it called > > > mac_alloc(), not the version of the framework (which the driver could > > > get at by calling some mac_version() function). > > > > This is already the existing proposal. Section 2: > > > > "The m_version field of the returned structure will have been > > automatically set to the requested version by mac_alloc()." > > Er, I read this part: > > * m_version will be set to MAC_VERSION (defined in ) by the > mac_alloc() function. This allows the mac module to know what > version of the MAC driver interface the driver was compiled against. > Drivers do not need to explicitly set this field. > > which seems to conflict with the part you quote. Good catch. That text needs to be modified to be consistent with section 2. Thank you. Once the dust has settled, I'll place an updated copy of the spec in the materials directory so that people don't have to rely on the mail trail. > Also, what are the error codes, if any, returned by mac_register() and > mac_unregister()? I only noticed something about what mac_unregister() > returns, nothing about what mac_register() returns (but I did not read > the materials that closely). That is indeed missing from the proposal. The function has changed enough that the set of error conditions is slightly different from the existing mac_register(), and we could stand to redefine these here. I'll post some text to that effect on this thread shortly and update the spec accordingly. Thanks, -Seb From sacadmin Tue Apr 18 08:35:19 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IFZIIQ024449 for ; Tue, 18 Apr 2006 08:35:18 -0700 (PDT) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k3IFZFPs010218; Tue, 18 Apr 2006 17:35:15 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k3IFZFDk007220; Tue, 18 Apr 2006 17:35:15 +0200 (MEST) Message-Id: <200604181535.k3IFZFDk007220@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Sebastien Roy , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: <1145371460.1345.18.camel@localhost> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> Date: Tue, 18 Apr 2006 17:35:15 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 716 >On Tue, 2006-04-18 at 10:02, Sebastien Roy wrote: >> > What would be required to support mac_register_t being a 'void *'? >> > >> > Or is doing that of no benefit here in paving the way towards a >> > stable API? >> >> I don't think it does no benefit, but I don't see how it addresses any >> architectural issues with the proposal. > >Use of void * may cause harm, actually -- my understanding is that use >of void * is known to create difficulty for mdb's post-mortem type >inference system (::typegraph, etc.,). So what about incomplete types where the CTF for the complete type is available? typedef struct mac_register mac_register_t; and only define that struct in the appropriate source files? Casper From sacadmin Tue Apr 18 10:49:01 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IHn1IQ007032 for ; Tue, 18 Apr 2006 10:49:01 -0700 (PDT) Received: from [129.146.11.214] (sr1-umpk-22.SFBay.Sun.COM [129.146.11.214]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.6) with ESMTP id k3IHn0kD354132; Tue, 18 Apr 2006 10:49:01 -0700 (PDT) Message-ID: <4445268C.3030802@Sun.COM> Date: Tue, 18 Apr 2006 10:49:00 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Peter Memishian CC: Sebastien Roy , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> In-Reply-To: <17477.942.147396.431791@triplex.East.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 944 Peter Memishian wrote On 04/18/06 08:20,: > > > Also, mac_alloc() can only return NULL or a mac_register_t. How will a > > > driver know if mac_alloc() failure was the result of version mismatch or > > > ENOMEM? This seems important, as failure to load a driver should result > > > in some useful diagnostic log message, but if mac_alloc() is the only > > > component that can make this particular distinction then users will have > > > to manually correlate log entries from it to driver load failures -- > > > decidely not friendly. > > > > You're right, so perhaps a pointer to an error code as an argument to > > mac_alloc() would be in order, and it would only be set if NULL is > > returned. How does that sound? > > > wait, I know of at least one project that currently needs to call mac_register() (thus mac_alloc() then mac_register() in the new scheme) from a Streams module's wput routine. Gotta allow ENOMEM Kais From sacadmin Tue Apr 18 11:34:20 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IIYKIQ010737 for ; Tue, 18 Apr 2006 11:34:20 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3IIYHbB026268; Tue, 18 Apr 2006 14:34:17 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k3IIYH1O008412; Tue, 18 Apr 2006 14:34:17 -0400 (EDT) Subject: Re: 2006/249 Nemo Changes for Binary Compatibility From: Bill Sommerfeld To: Kais Belgaied Cc: Peter Memishian , Sebastien Roy , Nicolas Williams , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com In-Reply-To: <4445268C.3030802@Sun.COM> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1145385257.7072.34.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Tue, 18 Apr 2006 14:34:17 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 306 On Tue, 2006-04-18 at 13:49, Kais Belgaied wrote: > wait, I know of at least one project that currently needs to call > mac_register() > (thus mac_alloc() then mac_register() in the new scheme) from a Streams > module's wput routine. can you be more specific about what this project is? - Bill From sacadmin Tue Apr 18 11:41:19 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IIfJIQ011152 for ; Tue, 18 Apr 2006 11:41:19 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXX00H01L0WW5@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 18 Apr 2006 14:41:19 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IXX0072LL5K2H@bur-mail2.east.sun.com>; Tue, 18 Apr 2006 14:39:20 -0400 (EDT) Date: Tue, 18 Apr 2006 14:39:02 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <4445268C.3030802@Sun.COM> To: Kais Belgaied Cc: Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <1145385542.3545.199.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> Status: RO Content-Length: 708 On Tue, 2006-04-18 at 10:49 -0700, Kais Belgaied wrote: > wait, I know of at least one project that currently needs to call > mac_register() > (thus mac_alloc() then mac_register() in the new scheme) from a Streams > module's > wput routine. Gotta allow ENOMEM I'd like to understand more about this before changing the interface to accommodate such a requirement. The mac_register() function _today_ (regardless of these proposed changes) blocks on a sleeping kmem_cache_alloc(). It would seem like this project has pre-existing design problems. If I had never come forward with this case, what would you (or your friend who is doing this project) have done to safely use the Nemo interfaces? -Seb From sacadmin Tue Apr 18 11:50:16 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IIoGIQ011460 for ; Tue, 18 Apr 2006 11:50:16 -0700 (PDT) Received: from [129.146.11.214] (sr1-umpk-22.SFBay.Sun.COM [129.146.11.214]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.6) with ESMTP id k3IIoFrm411376; Tue, 18 Apr 2006 11:50:15 -0700 (PDT) Message-ID: <444534E7.4080007@Sun.COM> Date: Tue, 18 Apr 2006 11:50:15 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Bill Sommerfeld CC: Peter Memishian , Sebastien Roy , Nicolas Williams , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385257.7072.34.camel@thunk> In-Reply-To: <1145385257.7072.34.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 613 Bill Sommerfeld wrote On 04/18/06 11:34,: >On Tue, 2006-04-18 at 13:49, Kais Belgaied wrote: > > >>wait, I know of at least one project that currently needs to call >>mac_register() >>(thus mac_alloc() then mac_register() in the new scheme) from a Streams >>module's wput routine. >> >> > >can you be more specific about what this project is? > > Crossbow, (project page: crossbow.eng)coming to an ARC review soon. Regardless, the existing aggr module currently calls mac_register() from a non-blockable path too. anyway, I saw Seb/Meem's answer. I'm happy. Kais. > - Bill > > > > > From sacadmin Tue Apr 18 11:57:40 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IIvdIQ011993 for ; Tue, 18 Apr 2006 11:57:40 -0700 (PDT) Received: from [129.146.11.214] (sr1-umpk-22.SFBay.Sun.COM [129.146.11.214]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.6) with ESMTP id k3IIvdPv413181; Tue, 18 Apr 2006 11:57:39 -0700 (PDT) Message-ID: <4445368B.3000902@Sun.COM> Date: Tue, 18 Apr 2006 11:57:15 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Sebastien Roy CC: Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> In-Reply-To: <1145385542.3545.199.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1184 Sebastien Roy wrote On 04/18/06 11:39,: >On Tue, 2006-04-18 at 10:49 -0700, Kais Belgaied wrote: > > >>wait, I know of at least one project that currently needs to call >>mac_register() >>(thus mac_alloc() then mac_register() in the new scheme) from a Streams >>module's >>wput routine. Gotta allow ENOMEM >> >> > >I'd like to understand more about this before changing the interface to >accommodate such a requirement. The mac_register() function _today_ >(regardless of these proposed changes) blocks on a sleeping >kmem_cache_alloc(). > > that would be a bug inside today's implementation of mac_register(). The mac_register interface itself returns ab error code. I am asking to make sure that mac_alloc() may fail because of memory allocation failure. For proper diagnosability, as long as that condition is distinguishable from the other error condition of version mismatch then I'm happy. Isn't that the case? Kais >It would seem like this project has pre-existing design problems. If I >had never come forward with this case, what would you (or your friend >who is doing this project) have done to safely use the Nemo interfaces? > >-Seb > > > > From sacadmin Tue Apr 18 12:01:44 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IJ1iIQ012032 for ; Tue, 18 Apr 2006 12:01:44 -0700 (PDT) Received: from [129.146.11.214] (sr1-umpk-22.SFBay.Sun.COM [129.146.11.214]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.6) with ESMTP id k3IJ1gxi415607; Tue, 18 Apr 2006 12:01:43 -0700 (PDT) Message-ID: <44453796.5000607@Sun.COM> Date: Tue, 18 Apr 2006 12:01:42 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Kais Belgaied CC: Sebastien Roy , Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> In-Reply-To: <4445368B.3000902@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 933 Kais Belgaied wrote On 04/18/06 11:57,: > > > Sebastien Roy wrote On 04/18/06 11:39,: > >> On Tue, 2006-04-18 at 10:49 -0700, Kais Belgaied wrote: >> >> >>> wait, I know of at least one project that currently needs to call >>> mac_register() >>> (thus mac_alloc() then mac_register() in the new scheme) from a >>> Streams module's >>> wput routine. Gotta allow ENOMEM >>> >> >> >> I'd like to understand more about this before changing the interface to >> accommodate such a requirement. The mac_register() function _today_ >> (regardless of these proposed changes) blocks on a sleeping >> kmem_cache_alloc(). >> >> > > that would be a bug inside today's implementation of mac_register(). > The mac_register interface itself returns ab error code. erratum: I mean: the mac_register() function as currently specified returns an error code, which could be ENOMEM, in case of mem alloc failure. Kais. From sacadmin Tue Apr 18 12:35:27 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IJZRIQ012907 for ; Tue, 18 Apr 2006 12:35:27 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k3IJZQ95007916; Tue, 18 Apr 2006 15:35:26 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k3IJZQcp007913; Tue, 18 Apr 2006 15:35:26 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17477.16254.247789.498281@triplex.East.Sun.COM> Date: Tue, 18 Apr 2006 15:35:26 -0400 To: Sebastien Roy Cc: Kais Belgaied , Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: <1145385542.3545.199.camel@localhost> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 569 > I'd like to understand more about this before changing the interface to > accommodate such a requirement. The mac_register() function _today_ > (regardless of these proposed changes) blocks on a sleeping > kmem_cache_alloc(). > > It would seem like this project has pre-existing design problems. If I > had never come forward with this case, what would you (or your friend > who is doing this project) have done to safely use the Nemo interfaces? I presume the issue is LAIOC_CREATE -> aggr_ioc_create() -> aggr_grp_create() -> mac_register()? -- meem From sacadmin Tue Apr 18 13:09:11 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IK9BIQ014175 for ; Tue, 18 Apr 2006 13:09:11 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k3IK9Aug008228; Tue, 18 Apr 2006 16:09:10 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k3IK9Anl008225; Tue, 18 Apr 2006 16:09:10 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17477.18278.589091.90934@triplex.East.Sun.COM> Date: Tue, 18 Apr 2006 16:09:10 -0400 To: Kais Belgaied Cc: Sebastien Roy , Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: <44453796.5000607@Sun.COM> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> <44453796.5000607@Sun.COM> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 338 > erratum: > I mean: the mac_register() function as currently specified returns > an error code, > which could be ENOMEM, in case of mem alloc failure. The issue is bigger than memory allocation. For instance, mac_register() also calls ddi_create_minor_node(9F), which requires a context that one can block in. -- meem From sacadmin Tue Apr 18 13:59:34 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IKxYIQ017254 for ; Tue, 18 Apr 2006 13:59:34 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXX00E01RLFR7@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 18 Apr 2006 16:59:34 -0400 (EDT) Received: from punchin-seb.East.Sun.COM (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IXX007KZRN9BN@bur-mail2.east.sun.com>; Tue, 18 Apr 2006 16:59:34 -0400 (EDT) Date: Tue, 18 Apr 2006 16:59:15 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <4445368B.3000902@Sun.COM> To: Kais Belgaied Cc: Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <1145393955.3545.220.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> Status: RO Content-Length: 2602 On Tue, 2006-04-18 at 11:57 -0700, Kais Belgaied wrote: > > Sebastien Roy wrote On 04/18/06 11:39,: > > >On Tue, 2006-04-18 at 10:49 -0700, Kais Belgaied wrote: > > > > > >>wait, I know of at least one project that currently needs to call > >>mac_register() > >>(thus mac_alloc() then mac_register() in the new scheme) from a Streams > >>module's > >>wput routine. Gotta allow ENOMEM > >> > >> > > > >I'd like to understand more about this before changing the interface to > >accommodate such a requirement. The mac_register() function _today_ > >(regardless of these proposed changes) blocks on a sleeping > >kmem_cache_alloc(). > > > > > > that would be a bug inside today's implementation of mac_register(). > The mac_register interface itself returns ab error code. Okay. So we can classify this as a problem with the existing framework that we have the opportunity to correct in this case. > > I am asking to make sure that mac_alloc() may fail because of memory > allocation failure. > For proper diagnosability, as long as that condition is distinguishable > from the other error condition of version mismatch then I'm happy. > Isn't that the case? We'd have to make some changes to both this case and 2006/248 to make that possible. The changes to this case would be: 1. Change mac_alloc() to have distinguishable error codes. I propose the following: mac_register_t *mac_alloc(uint_t mac_version, int *err); A NULL return value indicates an error, in which case the value of err is an errno error code. Upon error, err can either be EINVAL indicating a version mismatch, or ENOMEM indicating a memory allocation failure. 2. Make it clear that mac_register() does no sleeping allocations, and is therefore safe to use from a STREAMS context. The second of these changes will result in the following change to 2006/248 (and I'll send this change to that case log as well): The mactype_alloc() function will be modified as follows: mactype_register_t *mactype_alloc(uint_t mactype_version, int *err); The function will return NULL upon error, and err will be set to either EINVAL upon version mismatch, or ENOMEM for a memory allocation error. This needs to be done because mac_register() calls modload() to load the requested MAC-Type plugin. This in turn calls the plugin's _init() routine, which registers via mactype_alloc(). Therefore, if mac_register() can't block, then neither can mactype_alloc(). Do these changes satisfy the constraints for Crossbow or any other consumer that may be using these interfaces from similarly sensitive contexts? -Seb From sacadmin Tue Apr 18 14:07:59 2006 Received: from triplex.East.Sun.COM (triplex.East.Sun.COM [129.148.174.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3IL7wIQ018238 for ; Tue, 18 Apr 2006 14:07:59 -0700 (PDT) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k3IL7wtL009053; Tue, 18 Apr 2006 17:07:58 -0400 (EDT) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k3IL7w3a009050; Tue, 18 Apr 2006 17:07:58 -0400 (EDT) From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17477.21806.349187.657343@triplex.East.Sun.COM> Date: Tue, 18 Apr 2006 17:07:58 -0400 To: Sebastien Roy Cc: Kais Belgaied , Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: <1145393955.3545.220.camel@localhost> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> <1145393955.3545.220.camel@localhost> X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Status: RO Content-Length: 367 > 2. Make it clear that mac_register() does no sleeping allocations, and > is therefore safe to use from a STREAMS context. Again, the issue is not only with sleeping allocations, but with blocking in general. I haven't investigated this in detail, but I think it is non-trivial to ensure that there are no cv_wait()'s or the like along that codepath. -- meem From sacadmin Tue Apr 18 17:30:30 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3J0UTIQ029585 for ; Tue, 18 Apr 2006 17:30:29 -0700 (PDT) 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.12.10+Sun/8.12.9) with ESMTP id k3J0UNcv006092 for ; Wed, 19 Apr 2006 08:30:23 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IXY0090119IIB00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 08:30:22 +0800 (SGT) Received: from [129.158.87.138] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXY00DQB1EL36P3@mail-apac.sun.com>; Wed, 19 Apr 2006 08:30:22 +0800 (SGT) Date: Tue, 18 Apr 2006 17:28:47 -0700 From: Darren Reed Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <1145368922.3545.121.camel@localhost> Sender: Darren.Reed@Sun.COM To: Sebastien Roy Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <4445843F.2020002@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2547 Sebastien Roy wrote: >On Tue, 2006-04-18 at 01:03 -0700, Darren Reed wrote: > >>I appreciate that you're trying to improve the architecture of >>this interface here, but is this the right path to take? >> >>If I look across other 'alloc' functions that are part of stable >>interfaces in Solaris today, none of them take a version number. >> > >Similarity with memory allocation functions was never a requirement nor >a goal. This function retrieves a registration structure that can be >used to register. > Ok. I was just pondering about this from the point of view of if we were architecting APIs for the Solaris kernel and looking to set broad guidelines about what direction we were to go in, would this proposal fit within those guidelines. Stepping back from this project, is it within PSARC's charter to define what APIs inside Solaris look like or define what sort of model we should follow when designing new APIs? >The idea behind using a version number is that drivers that were >compiled against an incompatible version of the framework can be >gracefully rejected from allocating a registration structure and thus >from continuing to interact with the framework. Without this, a driver >could be passing in subtly incompatible data to the framework resulting >in panics. > I understand this. What I'm questioning is the method being proposed to achieve it. The mac_register_t structure has lots of different bits in it and it seems quite likely to evolve, even after it becomes stable. Going the version number path requires that the mac framework provides translation of the structures. If instead you were to opt for get/set functions, the problem changes. You're now free to change the structure and instead have to concentrate on what the accessor functions do, which may include thinking forward to how they behave if they become deprecated. If this is all documented then there's no need to have a version number passed into mac_alloc, although you may need to continue to include one in the mac_callbacks_t. >>If you were to provide a larger set of functions, set/get ones for >>each of the fields in mac_register_t, would there any need to specify >>a version number as is being done here? >> > >Yes, the version number is needed to prevent incompatible drivers from >using the framework at all instead of causing a panic down the road. > If you didn't expose the contents of the mac_register_t structure at all and programming to this interface used set/get functions, how would this lead to panics? Darren From sacadmin Tue Apr 18 17:34:15 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3J0YEIQ029732 for ; Tue, 18 Apr 2006 17:34:15 -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.12.10+Sun/8.12.9) with ESMTP id k3J0Y9cv006275 for ; Wed, 19 Apr 2006 08:34:09 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IXY00E011J37500@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 08:34:08 +0800 (SGT) Received: from [129.158.87.138] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXY008M71KS9BSC@mail-apac.sun.com>; Wed, 19 Apr 2006 08:34:05 +0800 (SGT) Date: Tue, 18 Apr 2006 17:32:30 -0700 From: Darren Reed Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <1145393955.3545.220.camel@localhost> Sender: Darren.Reed@Sun.COM To: Sebastien Roy Cc: Kais Belgaied , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <4445851E.90600@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> <1145393955.3545.220.camel@localhost> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 953 Sebastien Roy wrote: >On Tue, 2006-04-18 at 11:57 -0700, Kais Belgaied wrote: > > >>I am asking to make sure that mac_alloc() may fail because of memory >>allocation failure. >>For proper diagnosability, as long as that condition is distinguishable >>from the other error condition of version mismatch then I'm happy. >>Isn't that the case? >> >> > >We'd have to make some changes to both this case and 2006/248 to make >that possible. The changes to this case would be: > >1. Change mac_alloc() to have distinguishable error codes. I propose >the following: > >mac_register_t *mac_alloc(uint_t mac_version, int *err); >... >mactype_register_t *mactype_alloc(uint_t mactype_version, int *err); > > hmmm, when I saw this '*err' stuff, I was wondering if it would be possible to add a "int mac_getlasterror()" but there's no context for that call to have any relation to the others. Making that possible might be a bridge too far? Darren From sacadmin Tue Apr 18 17:47:41 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3J0leIQ000191 for ; Tue, 18 Apr 2006 17:47:40 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k3J0len5021760; Tue, 18 Apr 2006 20:47:40 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k3J0lelA021757; Tue, 18 Apr 2006 20:47:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17477.34988.85417.940449@gargle.gargle.HOWL> Date: Tue, 18 Apr 2006 20:47:40 -0400 From: James Carlson To: Darren Reed Cc: Sebastien Roy , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: Darren Reed's message of 18 April 2006 17:28:47 References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <4445843F.2020002@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1656 Darren Reed writes: > Stepping back from this project, is it within PSARC's charter to > define what APIs inside Solaris look like or define what sort of > model we should follow when designing new APIs? Yes, but in general we'd prefer to have others define those models and then propose them to *us*. The "R" in PSARC means "review." > even after it becomes stable. Going the version number path > requires that the mac framework provides translation of the > structures. Not necessarily, I think. It can just fail the request, if that's what's best. > If instead you were to opt for get/set functions, the problem > changes. You're now free to change the structure and instead > have to concentrate on what the accessor functions do, which > may include thinking forward to how they behave if they become > deprecated. If this is all documented then there's no need to I don't think that really fixes the problem. It opens the question of what to do when the get/set objects themselves are either removed or refactored into other objects, or acquire new semantics. In other words, you face the same set of issues that you had with changes to the data structure, just in a different form. The only problem it seems to solve is that if there's some object nobody uses, then you can delete it completely without harm. But since you can also ignore a no-longer-needed structure member, it seems like a marginal benefit. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Apr 18 17:55:25 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.105]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3J0tOIQ000891 for ; Tue, 18 Apr 2006 17:55:24 -0700 (PDT) Received: from [129.146.11.214] (sr1-umpk-22.SFBay.Sun.COM [129.146.11.214]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.6) with ESMTP id k3J0tOVY883109; Tue, 18 Apr 2006 17:55:24 -0700 (PDT) Message-ID: <44458A72.80906@Sun.COM> Date: Tue, 18 Apr 2006 17:55:14 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Sebastien Roy CC: Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> <1145393955.3545.220.camel@localhost> In-Reply-To: <1145393955.3545.220.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2421 Sebastien Roy wrote On 04/18/06 13:59,: >We'd have to make some changes to both this case and 2006/248 to make >that possible. The changes to this case would be: > >1. Change mac_alloc() to have distinguishable error codes. I propose >the following: > >mac_register_t *mac_alloc(uint_t mac_version, int *err); > >A NULL return value indicates an error, in which case the value of err >is an errno error code. Upon error, err can either be EINVAL indicating >a version mismatch, or ENOMEM indicating a memory allocation failure. > > > yes. I think that's what's needed to know the tell them apart. >2. Make it clear that mac_register() does no sleeping allocations, and >is therefore safe to use from a STREAMS context. > >The second of these changes will result in the following change to >2006/248 (and I'll send this change to that case log as well): > >The mactype_alloc() function will be modified as follows: > >mactype_register_t *mactype_alloc(uint_t mactype_version, int *err); > >The function will return NULL upon error, and err will be set to either >EINVAL upon version mismatch, or ENOMEM for a memory allocation error. > > or EFAULT if the actual loading of the plugin's binary into kernel memory fails. >This needs to be done because mac_register() calls modload() to load the > > this is more troublesome (see Meem's comment). I don't think it blocks progress for the 2006/249 case (Nemo changes for Binary compatibility) though, since it doesn't make things any worse, and the problem doesn't preclude from delivering the changes needed to make Nemo future evolutions compatible. A couple of cases are on their way and depend on 2006/249. >requested MAC-Type plugin. This in turn calls the plugin's _init() >routine, which registers via mactype_alloc(). Therefore, if >mac_register() can't block, then neither can mactype_alloc(). > >Do these changes satisfy the constraints for Crossbow or any other >consumer that may be using these interfaces from similarly sensitive >contexts? > > I see two choices here: . either assert that mac_register()'s shall not be called from non blockable context, and file a bug to change the aggr module accordingly, and advice the Crossbow project to follow. . or introduce/use some agent/daemon in the system that does the loading/registration on behalf of callers of mac_register()/mactype_alloc(). Kais >-Seb > > > > From sacadmin Tue Apr 18 19:39:53 2006 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3J2dqIQ002303 for ; Tue, 18 Apr 2006 19:39:53 -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.12.10+Sun/8.12.9) with ESMTP id k3J2dkFV022460 for ; Wed, 19 Apr 2006 10:39:46 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IXY009017ARCR00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 10:39:46 +0800 (SGT) Received: from [129.158.87.138] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IXY00DVT7E93684@mail-apac.sun.com>; Wed, 19 Apr 2006 10:39:46 +0800 (SGT) Date: Tue, 18 Apr 2006 19:38:11 -0700 From: Darren Reed Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <17477.34988.85417.940449@gargle.gargle.HOWL> Sender: Darren.Reed@Sun.COM To: James Carlson Cc: Sebastien Roy , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <4445A293.6050102@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <4445843F.2020002@sun.com> <17477.34988.85417.940449@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1531 James Carlson wrote: >Darren Reed writes: > >>If instead you were to opt for get/set functions, the problem >>changes. You're now free to change the structure and instead >>have to concentrate on what the accessor functions do, which >>may include thinking forward to how they behave if they become >>deprecated. If this is all documented then there's no need to >> > >I don't think that really fixes the problem. > >It opens the question of what to do when the get/set objects >themselves are either removed or refactored into other objects, or >acquire new semantics. In other words, you face the same set of >issues that you had with changes to the data structure, just in a >different form. > Removing a get/set object can result in one of two things: * loader failure (unresolved symbol) * error being returned both of these scenarios are much friendlier than a panic due to a structure changing. If I declare a function to be "Stable" in an API, is changing its semantics allowed? Or would I need to introduce a new function? If I want to add/remove a new field to mac_register_t, I need to rev the entire framework, regardless of the purpose of the change to the structure. On a different note... With the evolution of other functions to take an "int *" for the error, shouldn't we have: mac_handle_t mac_register(mac_register_t *, int *) (this isn't a required change but does give the appearance of a consistent design rather than a patchwork approach.) Either that or all have them all return int. Darren From sacadmin Tue Apr 18 19:54:59 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3J2swIQ002916 for ; Tue, 18 Apr 2006 19:54:58 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k3J2swHM022134; Tue, 18 Apr 2006 22:54:58 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k3J2swEv022131; Tue, 18 Apr 2006 22:54:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17477.42626.132064.697139@gargle.gargle.HOWL> Date: Tue, 18 Apr 2006 22:54:58 -0400 From: James Carlson To: Darren Reed Cc: Sebastien Roy , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: Darren Reed's message of 18 April 2006 19:38:11 References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <4445843F.2020002@sun.com> <17477.34988.85417.940449@gargle.gargle.HOWL> <4445A293.6050102@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2624 Darren Reed writes: > Removing a get/set object can result in one of two things: > * loader failure (unresolved symbol) > * error being returned > > both of these scenarios are much friendlier than a panic > due to a structure changing. I disagree, for two reasons. First, there's no panic that I can see involved here. The version number is checked, and if the version is too far out of date, the driver doesn't load at all. If it really were a question of panicking, I'd say that no solution that uses a panic on a non-debug system to report "out of date" or any other usage error is acceptable. Secondly, and much more importantly, get/set behavior is driven by the run-time software behavior, rather than being a static check at initialization time like a version number. This means that an incompatible driver will run for a while -- until the user tries to do something "unusual" like send a multicast frame, and then it fails. What do you do then? You can't just unload yourself after failure. > If I declare a function to be "Stable" in an API, is changing > its semantics allowed? Generally, no, but we'd need to see a concrete case to give a concrete answer. > Or would I need to introduce a new function? Perhaps. > If I want to add/remove a new field to mac_register_t, I need to > rev the entire framework, regardless of the purpose of the change > to the structure. Not so. Adding new members to the end is harmless as long as either (a) the framework itself does the allocation/free or (b) the interface from the client supplies either length or version. Adding new meanings or even restricting values in already-existing members is possible as well, depending on circumstances. I don't see a huge difference between using a structure and having a get/set interface, other than that the latter may well be a lot more cumbersome to use and maintain. It's a lot of function calls, and if it's not stuff that you need to set on the fly, I see no purpose to it. > mac_handle_t mac_register(mac_register_t *, int *) > > (this isn't a required change but does give the appearance of > a consistent design rather than a patchwork approach.) I'd actually defer to the project team (and their design reviewers) to choose a design that's appropriate for the subsystem in question. (Which is another way of saying that I think it's possible to have _too much_ consistency.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Apr 18 23:42:13 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3J6gDIQ008356 for ; Tue, 18 Apr 2006 23:42:13 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3J6gCES002846; Wed, 19 Apr 2006 01:42:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3J6gCIR002845; Wed, 19 Apr 2006 01:42:12 -0500 (CDT) Date: Wed, 19 Apr 2006 01:42:12 -0500 From: Nicolas Williams To: Darren Reed Cc: Sebastien Roy , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility Message-ID: <20060419064212.GS1274@binky.Central.Sun.COM> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <4445843F.2020002@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4445843F.2020002@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1983 On Tue, Apr 18, 2006 at 05:28:47PM -0700, Darren Reed wrote: > I understand this. What I'm questioning is the method being > proposed to achieve it. The mac_register_t structure has lots > of different bits in it and it seems quite likely to evolve, > even after it becomes stable. Going the version number path > requires that the mac framework provides translation of the > structures. Actually, mac_register_t has relatively few and unlikely-to-change bits, BUT, many could be moved to mac_callbacks_t. How the decision is made to have some bits specified this way and some the other I don't know, but it seems that simple read-once stuff goes into mac_register_t and actions (e.g., transmit) and complicated stuff (e.g., capabilities) go into mac_callbacks_t, which seems reasonable to me. I think a more opaque type and accessor API would be fine here since this is initialization-only stuff and the extra function calls would be a wash, but though I'm a fan of opaque types and accessor APIs I'd say it's not necessary here, and might even lead to harder to driver code being harder to read. Also, to truly be extensible you'd have to have this sequence: - init registration - register this - register that - ... - finish registration And then you have to worry about reasonable defaults to things left out by drivers, or how to indicate what was required but not given... > If instead you were to opt for get/set functions, the problem > changes. You're now free to change the structure and instead > have to concentrate on what the accessor functions do, which > may include thinking forward to how they behave if they become > deprecated. If this is all documented then there's no need to > have a version number passed into mac_alloc, although you may > need to continue to include one in the mac_callbacks_t. You could have each callback registered separately if you wanted to avoid mac_callbacks_t, but now you see that opacity has its price. Nico -- From sacadmin Wed Apr 19 01:17:28 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3J8HRIQ010198 for ; Wed, 19 Apr 2006 01:17:27 -0700 (PDT) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k3J8HJPs014478; Wed, 19 Apr 2006 10:17:19 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k3J8HJDk009781; Wed, 19 Apr 2006 10:17:19 +0200 (MEST) Message-Id: <200604190817.k3J8HJDk009781@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Sebastien Roy cc: Kais Belgaied , Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-Reply-To: <1145393955.3545.220.camel@localhost> References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> <1145393955.3545.220.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Apr 2006 10:17:19 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 710 >We'd have to make some changes to both this case and 2006/248 to make >that possible. The changes to this case would be: > >1. Change mac_alloc() to have distinguishable error codes. I propose >the following: > >mac_register_t *mac_alloc(uint_t mac_version, int *err); Will this function succeed if called with a different version number? (As others have indicated, the version number sounds a bad idea). Why are we *forcing* non-sleep allocations? Why can't we have a KM_FLAGS argument? It's an *alloc() function so a KM_SLEEP, KM_NOSLEEP argument seems perfectly appropriate. Do we really want the possibility that a temporary memory shortfall will cause an interface attach to fail? Casper From sacadmin Wed Apr 19 10:38:39 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3JHcdIQ002153 for ; Wed, 19 Apr 2006 10:38:39 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXZ00301CZML7@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 13:38:38 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXZ00C00D0DML@bur-mail2.east.sun.com>; Wed, 19 Apr 2006 13:38:38 -0400 (EDT) Date: Wed, 19 Apr 2006 13:38:37 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <44458A72.80906@Sun.COM> To: Kais Belgaied Cc: Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <4446759D.3010906@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> <1145393955.3545.220.camel@localhost> <44458A72.80906@Sun.COM> Status: RO Content-Length: 1886 Kais Belgaied wrote: > Sebastien Roy wrote On 04/18/06 13:59,: > >> 2. Make it clear that mac_register() does no sleeping allocations, and >> is therefore safe to use from a STREAMS context. >> >> The second of these changes will result in the following change to >> 2006/248 (and I'll send this change to that case log as well): >> >> The mactype_alloc() function will be modified as follows: >> >> mactype_register_t *mactype_alloc(uint_t mactype_version, int *err); >> >> The function will return NULL upon error, and err will be set to either >> EINVAL upon version mismatch, or ENOMEM for a memory allocation error. >> >> > > or EFAULT if the actual loading of the plugin's binary into kernel > memory fails. > >> This needs to be done because mac_register() calls modload() to load the >> >> > > > this is more troublesome (see Meem's comment). Yes, and it underlines that the existing mac_register() mechanism is not safe to use from interrupt context or any other context that is sensitive to blocking. Changing this architectural property of mac_register() is non-trivial, and at this point, I'm going to assert that it is outside the scope of this case to address that. > > I see two choices here: > . either assert that mac_register()'s shall not be called from non > blockable context, and > file a bug to change the aggr module accordingly, and advice the > Crossbow project to follow. This is what we are going to do. What we are going to do is keep the allocation and registration interfaces as-is in the original proposal, and explicitly state that these interfaces may block and aren't safe from those contexts. A bug will be filed against the aggr module. There is nothing being proposed in this architecture that precludes a future project from changing that, including implementing an allocation function that can return ENOMEM. -Seb From sacadmin Wed Apr 19 10:51:56 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3JHpuIQ002637 for ; Wed, 19 Apr 2006 10:51:56 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXZ00A01DLLO5@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 13:51:56 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXZ00CRFDMJML@bur-mail2.east.sun.com>; Wed, 19 Apr 2006 13:51:56 -0400 (EDT) Date: Wed, 19 Apr 2006 13:51:55 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <200604190817.k3J8HJDk009781@vaticaan.Holland.Sun.COM> To: Casper.Dik@Sun.COM Cc: Kais Belgaied , Peter Memishian , Nicolas Williams , Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM Message-id: <444678BB.5010008@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <17477.942.147396.431791@triplex.East.Sun.COM> <4445268C.3030802@Sun.COM> <1145385542.3545.199.camel@localhost> <4445368B.3000902@Sun.COM> <1145393955.3545.220.camel@localhost> <200604190817.k3J8HJDk009781@vaticaan.Holland.Sun.COM> Status: RO Content-Length: 1518 Casper.Dik@Sun.COM wrote: > > >> We'd have to make some changes to both this case and 2006/248 to make >> that possible. The changes to this case would be: >> >> 1. Change mac_alloc() to have distinguishable error codes. I propose >> the following: >> >> mac_register_t *mac_alloc(uint_t mac_version, int *err); > > Will this function succeed if called with a different version number? If the version the driver was compiled against is incompatible with the supported versions implemented by the mac module, then it will fail. Given the proposed architecture and extensibility of both driver callbacks and capabilities, however, I don't foresee anyone ever needing to bump the version number and creating an incompatible version. The extensibility of the API is in the driver callbacks and capabilities mechanism (mc_getcapab()). Those can be grown at will in a completely compatible way, which is the strength of this API. > > Why are we *forcing* non-sleep allocations? Why can't we have a KM_FLAGS > argument? It's an *alloc() function so a KM_SLEEP, KM_NOSLEEP argument > seems perfectly appropriate. > > Do we really want the possibility that a temporary memory shortfall will > cause an interface attach to fail? I've just nipped this one in the bud. The original proposal will stand, and this API will not be safe to use from blocking sensitive contexts. Both mac_alloc() and mac_register() may sleep while waiting for memory, and for other conditions tied to the implementation. -Seb From sacadmin Wed Apr 19 11:13:13 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3JIDDIQ005044 for ; Wed, 19 Apr 2006 11:13:13 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXZ00L01EIXXE@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 14:13:13 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXZ00C5YELZML@bur-mail2.east.sun.com>; Wed, 19 Apr 2006 14:13:12 -0400 (EDT) Date: Wed, 19 Apr 2006 14:13:11 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <20060418152437.GK26823@binky.Central.Sun.COM> To: Nicolas Williams Cc: Bill Sommerfeld , Darren Reed , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <44467DB7.3070604@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) References: <443EBE18.4040409@sun.com> <44449D60.6090903@sun.com> <1145368922.3545.121.camel@localhost> <1145371460.1345.18.camel@localhost> <20060418145845.GH26823@binky.Central.Sun.COM> <1145372561.3545.132.camel@localhost> <20060418151248.GI26823@binky.Central.Sun.COM> <1145373467.3545.138.camel@localhost> <20060418152437.GK26823@binky.Central.Sun.COM> Status: RO Content-Length: 1078 Nicolas Williams wrote: > Also, what are the error codes, if any, returned by mac_register() and > mac_unregister()? I only noticed something about what mac_unregister() > returns, nothing about what mac_register() returns (but I did not read > the materials that closely). The following will be specified in the updated spec: Possible return values for mac_register() include: 0 On success. EINVAL The mac_register_t contains an invalid field. This can include a MAC-Type plugin that couldn't be found or loaded, missing callbacks, or a missing source address. EEXIST The device being registered was already registered. The registration structure can be freed after registration using the mac_free() function. When the device detaches and needs to unregister, it passes this handle into mac_unregister(). The mac_unregister() function may fail and will have the following possible return values: 0 On success. EBUSY The MAC is in use by a data-link and cannot be unregistered. -Seb From sacadmin Wed Apr 19 14:26:17 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3JLQHIQ020019 for ; Wed, 19 Apr 2006 14:26:17 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXZ00801NDUYE@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 17:26:16 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXZ00HQRNJS62@bur-mail2.east.sun.com>; Wed, 19 Apr 2006 17:26:16 -0400 (EDT) Date: Wed, 19 Apr 2006 17:26:16 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <443EBE18.4040409@sun.com> To: Sebastien Roy Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <4446AAF8.9050700@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) References: <443EBE18.4040409@sun.com> Status: RO Content-Length: 2068 The discussions surrounding this case have been lengthy, but I believe all issues have been addressed. The timer will be allowed to run until tomorrow. Until then, all issues have been addressed in an updated spec, which I have placed in the case directory. here's a summary of the issues that were brought up and how they have been resolved: Randy Fishel: ------------- ISSUE: Why are the interfaces still Consolidation Private RESOLUTION: No action. That will be handled by the Nemo team in a separate case. Darren Reed: ------------ ISSUE: Why not use accessor functions with an opaque mac_register_t? RESOLUTION: No action. There is no architectural value in modifying the proposal in this way, and this doesn't solve any architectural problem with the proposal. Nicolas Williams: ----------------- ISSUE: The description of m_version is section 2.1 is inconsistent with section 2. RESOLUTION: Section 2.1 has been fixed to be clear that mac_alloc() sets m_version to the requested version. ISSUE: What are the error codes returned by mac_register() and mac_unregister()? RESOLUTION: This has been specified in the updated spec. Kais Belgaied: -------------- ISSUE: Projects may need to call mac_alloc()/mac_register() from blocking sensitive contexts, so it's not okay if mac_alloc() does a sleeping allocation. The aggr module currently calls mac_register() while handling an ioctl mblk. RESOLUTION: mac_register() is already unsafe from such contexts, and this case isn't changing that, nor making things any worse. Future projects will need to be mindful of that restriction in the API. The following bug has been filed against the aggr module: 6415485 aggr shouldn't call blocking mac_register() while handling ioctl message I'm also making a minor modification to mac_pdata_update(). As proposed, it returned void, but I've modified it to return int as the MAC-Type plugin data verification could fail (as specified in 2006/248), and mac_pdata_update() needs to be able to fail with EINVAL in that case. Thanks, -Seb From sacadmin Wed Apr 19 14:31:47 2006 Received: from sandieji.prc.sun.com (sandieji.PRC.Sun.COM [129.158.215.122]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3JLVkIQ020109 for ; Wed, 19 Apr 2006 14:31:47 -0700 (PDT) Received: from [129.158.218.199] (beyond [129.158.218.199]) by sandieji.prc.sun.com (8.13.2+Sun/8.13.2) with ESMTP id k3JLVjX4001153; Thu, 20 Apr 2006 05:31:45 +0800 (CST) Message-ID: <4446AC3B.4090407@sun.com> Date: Thu, 20 Apr 2006 05:31:39 +0800 From: "Lu Yun-Song (Roamer)" User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastien Roy CC: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> In-Reply-To: <443EBE18.4040409@sun.com> Content-Type: multipart/alternative; boundary="------------020104010602070508000008" Status: RO Content-Length: 3960 This is a multi-part message in MIME format. --------------020104010602070508000008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (Sorry for the delay comments) Sebastien Roy wrote: > 2.1 mac_register_t > ------------------ > uint8_t *m_src_addr; > uint8_t *m_dst_addr; Even I don't know any case, I guess it's possible to set multiple mac addresses by vendors in the future. So I suggest to negotiate these two addrs as h/w capability. ... > uint_t m_min_sdu; > uint_t m_max_sdu; How about to regard SDU also as a negotiable capability? Jumbo Frame is more popular and driver maybe want to set default MTU that is different with (max_sdu + ether_hdr). If the driver don't negotiate this capability, just set them to default values, 0 and 1500. For both cases, I don't see strong reasons to keep them in mac_register_t. :-) If moving these capability out, this data structure should be more clean. Thanks, Roamer > * m_min_sdu is set to the minimum payload size that can be conveyed > by the > media. > > * m_max_sdu is set to the maximum payload size that can be conveyed > by the > media. -- # /telnet +86-10-82618200 x82227/ Connected to OPG.Sun.COM. login: /Roamer.Lu@Sun.COM/ Last login: Mon Dec 22, 2003 from /beyond.prc/ Welcome! *Lu Yun-Song* [Roamer@Solaris Network]# --------------020104010602070508000008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit (Sorry for the delay comments)
Sebastien Roy wrote:
2.1 mac_register_t
------------------
    uint8_t        *m_src_addr;
    uint8_t        *m_dst_addr;
Even I don't know any case, I guess it's possible to set multiple mac addresses by vendors in the future.
So I suggest to negotiate these two addrs as h/w capability.
...
    uint_t        m_min_sdu;
    uint_t        m_max_sdu;
How about to regard SDU also as a negotiable capability? Jumbo Frame is more popular and driver maybe want to set default MTU that is different with (max_sdu + ether_hdr).
If the driver don't negotiate this capability, just set them to default values, 0 and 1500.

For both cases, I don't see strong reasons to keep them in mac_register_t. :-)  If moving these capability out, this data structure should be more clean.

Thanks,

Roamer

   * m_min_sdu is set to the minimum payload size that can be conveyed by the
     media.

   * m_max_sdu is set to the maximum payload size that can be conveyed by the
     media.

--

# telnet +86-10-82618200  x82227
Connected to OPG.Sun.COM.
login: Roamer.Lu@Sun.COM
Last login: Mon Dec 22, 2003 from beyond.prc
Welcome! Lu Yun-Song
[Roamer@Solaris Network]#




--------------020104010602070508000008-- From sacadmin Wed Apr 19 14:39:51 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3JLdpIQ020271 for ; Wed, 19 Apr 2006 14:39:51 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXZ00F01NZL6I@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 17:39:51 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXZ00HPUO6E62@bur-mail2.east.sun.com>; Wed, 19 Apr 2006 17:39:51 -0400 (EDT) Date: Wed, 19 Apr 2006 17:39:50 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <4446AC3B.4090407@sun.com> To: "Lu Yun-Song (Roamer)" Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <4446AE26.7010505@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> Status: RO Content-Length: 1486 Lu Yun-Song (Roamer) wrote: > (Sorry for the delay comments) > Sebastien Roy wrote: >> 2.1 mac_register_t >> ------------------ >> uint8_t *m_src_addr; >> uint8_t *m_dst_addr; > Even I don't know any case, I guess it's possible to set multiple mac > addresses by vendors in the future. > So I suggest to negotiate these two addrs as h/w capability. There's an upcoming PSARC case (currently under design review) that's proposing to do this as a MAC capability to add _additional_ addresses. There's no need to modify the mac_register_t to do this. > ... >> uint_t m_min_sdu; >> uint_t m_max_sdu; > How about to regard SDU also as a negotiable capability? Jumbo Frame is > more popular and driver maybe want to set default MTU that is different > with (max_sdu + ether_hdr). > If the driver don't negotiate this capability, just set them to default > values, 0 and 1500. Negotiate what? An initial minimum and maximum SDU needs to be specified, regardless of whether that changes. An additional MAC driver interface can be added in the future to _update_ the MTU (and I'm going to do that as part of the tunneling work in Clearview), but there's absolutely no case where a driver would have no MTU... > > For both cases, I don't see strong reasons to keep them in > mac_register_t. :-) If moving these capability out, this data structure > should be more clean. I see no reason to remove them from mac_register_t. -Seb From sacadmin Wed Apr 19 14:43:36 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3JLhaIQ020627 for ; Wed, 19 Apr 2006 14:43:36 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXZ00H01O6P0B@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 17:43:35 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IXZ00HGTOCN62@bur-mail2.east.sun.com>; Wed, 19 Apr 2006 17:43:35 -0400 (EDT) Date: Wed, 19 Apr 2006 17:43:35 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <4446AAF8.9050700@sun.com> To: Sebastien Roy Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <4446AF07.20402@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060327) References: <443EBE18.4040409@sun.com> <4446AAF8.9050700@sun.com> Status: RO Content-Length: 643 Sebastien Roy wrote: > Until then, all issues have been addressed in an updated spec, > which I have placed in the case directory. The updated spec also contains a definition for mac_capab_t, which is an enumerated type for MAC capability values. The following definitions have been modified to reflect that: In section 2.2.2: typedef boolean_t (*mac_getcapab_t)(void *arg, mac_capab_t capab, void *data); typedef enum { MAC_CAPAB_HCKSUM, MAC_CAPAB_POLL /* new capabilities are defined here */ } mac_capab_t; And in section 4.1.1: boolean_t mac_capab_get(mac_handle_t mh, mac_capab_t cap, void *cap_data); -Seb From sacadmin Wed Apr 19 18:30:03 2006 Received: from sandieji.prc.sun.com (sandieji-216-a.PRC.Sun.COM [129.158.216.179]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3K1U2IQ003106 for ; Wed, 19 Apr 2006 18:30:03 -0700 (PDT) Received: from [129.158.218.199] (beyond [129.158.218.199]) by sandieji.prc.sun.com (8.13.2+Sun/8.13.2) with ESMTP id k3K1TvbB005977; Thu, 20 Apr 2006 09:29:57 +0800 (CST) Message-ID: <4446E40F.7080103@sun.com> Date: Thu, 20 Apr 2006 09:29:51 +0800 From: "Lu Yun-Song (Roamer)" User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastien Roy CC: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, crossbow-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> In-Reply-To: <4446AE26.7010505@sun.com> Content-Type: multipart/alternative; boundary="------------020402050108020209070709" Status: RO Content-Length: 9609 This is a multi-part message in MIME format. --------------020402050108020209070709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (cc'ed crossbow team) Sebastien Roy wrote: >>> 2.1 mac_register_t >>> ------------------ >>> uint8_t *m_src_addr; >>> uint8_t *m_dst_addr; >> >> Even I don't know any case, I guess it's possible to set multiple mac >> addresses by vendors in the future. >> So I suggest to negotiate these two addrs as h/w capability. > > There's an upcoming PSARC case (currently under design review) that's > proposing to do this as a MAC capability to add _additional_ > addresses. There's no need to modify the mac_register_t to do this. I think I know the case you mentioned, that is to implement new interfaces to set multiple mac unicast addresses, but I'm trying to address something else. In the future, it's possible some vendor will provide multiple mac addresses with alone card that support multiple channel for tx/rx. At that time, how you set m_src_addr with multiple vendor-supplied addrs? This single unicast address in mac_register_t should not make sense. As you descibed, m_dst_addr is optional. So why to open such obscure optional interface to driver but not to move it to capability negotiation? ;-) >> ... >> >>> uint_t m_min_sdu; >>> uint_t m_max_sdu; >> >> How about to regard SDU also as a negotiable capability? Jumbo Frame >> is more popular and driver maybe want to set default MTU that is >> different with (max_sdu + ether_hdr). >> If the driver don't negotiate this capability, just set them to >> default values, 0 and 1500. > > Negotiate what? An initial minimum and maximum SDU needs to be > specified, regardless of whether that changes. An additional MAC > driver interface can be added in the future to _update_ the MTU (and > I'm going to do that as part of the tunneling work in Clearview), but > there's absolutely no case where a driver would have no MTU... (to simplify the description, we'll use SDU is MTU without difference) This way was designed with GLDv2 or even older GLD version, it was enough for nic drivers before JumboFrame is supported. To ask every Ethernet driver to set m_max_sdu to 1500 is unnecessary, and that is lack of extension. Indeed, to initiate a nic driver need two parameters of MTU, maximum MTU and default MTU. The max_mtu is used to make sure the driver/nic is configured with supported MTU, and the default MTU is used to initiate the instance with appropriate size of tx/rx buffers and hardware configuration. GLDv2 and Nemo are using max_sdu as default MTU, so the way to enable Jumbo is not flexible enough. I'm sure the way need to be changed soon, but the first thing is to move the interface out of mac_register_t to avoid further breaking binaries compitibility. The suggested logic is: * If the nic don't negotiatiate MTU. Set both max_mtu and default_mtu to 1500 * To enable Jumbo Frame, Driver need to negotiate the capability with these informations: max_mtu, default_mtu, min_mtu >> For both cases, I don't see strong reasons to keep them in >> mac_register_t. :-) If moving these capability out, this data >> structure should be more clean. > > I see no reason to remove them from mac_register_t. The benefit of removing them from mac_register_t is this data structure should only includ "soft" informations so that interface will be more stable. With hardware evolving, any hardware capability is possibly changed, so keep these "h/w related capabilities" in mac_register_t is not better than negotiate them one by one. I don't know what's the policy you decided to keeep which information in mac_register_t and move which capability out. So I'd like to see that *only s/w informations of the instance are included in mac_register_t*, and "to negotiate all hardware capabilities with driver". :-) Thanks, Roamer -- # /telnet +86-10-82618200 x82227/ Connected to OPG.Sun.COM. login: /Roamer.Lu@Sun.COM/ Last login: Mon Dec 22, 2003 from /beyond.prc/ Welcome! *Lu Yun-Song* [Roamer@Solaris Network]# --------------020402050108020209070709 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit (cc'ed crossbow team)
Sebastien Roy wrote:
2.1 mac_register_t
------------------
    uint8_t        *m_src_addr;
    uint8_t        *m_dst_addr;
Even I don't know any case, I guess it's possible to set multiple mac addresses by vendors in the future.
So I suggest to negotiate these two addrs as h/w capability.
There's an upcoming PSARC case (currently under design review) that's proposing to do this as a MAC capability to add _additional_ addresses.  There's no need to modify the mac_register_t to do this.
I think I know the case you mentioned, that is to implement new interfaces to set multiple mac unicast addresses, but I'm trying to address something else.
In the future, it's possible some vendor will provide multiple mac addresses with alone card that support multiple channel for tx/rx. At that time, how you set m_src_addr with multiple vendor-supplied addrs? This single unicast address in mac_register_t should not make sense.
As you descibed, m_dst_addr is optional. So why to open such obscure optional interface to driver but not to move it to capability negotiation? ;-)
...
    uint_t        m_min_sdu;
    uint_t        m_max_sdu;
How about to regard SDU also as a negotiable capability? Jumbo Frame is more popular and driver maybe want to set default MTU that is different with (max_sdu + ether_hdr).
If the driver don't negotiate this capability, just set them to default values, 0 and 1500.
Negotiate what?  An initial minimum and maximum SDU needs to be specified, regardless of whether that changes.  An additional MAC driver interface can be added in the future to _update_ the MTU (and I'm going to do that as part of the tunneling work in Clearview), but there's absolutely no case where a driver would have no MTU...
(to simplify the description, we'll use SDU is MTU without difference)

This way was designed with GLDv2 or even older GLD version, it was enough for nic drivers before JumboFrame is supported.
To ask every Ethernet driver to set m_max_sdu to 1500 is unnecessary, and that is lack of extension.
Indeed, to initiate a nic driver need two parameters of MTU, maximum MTU and default MTU. The max_mtu is used to make sure the driver/nic is configured with supported MTU, and the default MTU is used to initiate the instance with appropriate size of tx/rx buffers and hardware configuration. GLDv2 and Nemo are using max_sdu as default MTU, so the way to enable Jumbo is not flexible enough.
I'm sure the way need to be changed soon, but the first thing is to move the interface out of mac_register_t to avoid further breaking binaries compitibility. The suggested logic is:
    * If the nic don't negotiatiate MTU. Set both max_mtu and default_mtu to 1500
    * To enable Jumbo Frame, Driver need to negotiate the capability with these informations: max_mtu, default_mtu, min_mtu
For both cases, I don't see strong reasons to keep them in mac_register_t. :-)  If moving these capability out, this data structure should be more clean.
I see no reason to remove them from mac_register_t.
The benefit of removing them from mac_register_t is this data structure should only includ "soft" informations so that interface will be more stable. With hardware evolving, any hardware capability is possibly changed, so keep these "h/w related capabilities" in mac_register_t is not better than negotiate them one by one.

I don't know what's the policy you decided to keeep which information in mac_register_t and move which capability out. So I'd like to see that *only s/w informations of the instance are included in mac_register_t*, and "to negotiate all hardware capabilities with driver". :-)

Thanks,

Roamer
--

# telnet +86-10-82618200  x82227
Connected to OPG.Sun.COM.
login: Roamer.Lu@Sun.COM
Last login: Mon Dec 22, 2003 from beyond.prc
Welcome! Lu Yun-Song
[Roamer@Solaris Network]#




--------------020402050108020209070709-- From sacadmin Wed Apr 19 19:40:04 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3K2e3IQ006078 for ; Wed, 19 Apr 2006 19:40:04 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IY0006011MMJ1@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Wed, 19 Apr 2006 22:40:03 -0400 (EDT) Received: from [129.148.19.4] (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IY0008FE22R1Y@bur-mail2.east.sun.com>; Wed, 19 Apr 2006 22:40:03 -0400 (EDT) Date: Wed, 19 Apr 2006 22:39:40 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <4446E40F.7080103@sun.com> To: "Lu Yun-Song (Roamer)" Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, crossbow-iteam@sun.com Message-id: <4446F46C.3060506@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060410) References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> Status: RO Content-Length: 5501 Lu Yun-Song (Roamer) wrote: > I think I know the case you mentioned, that is to implement new > interfaces to set multiple mac unicast addresses, but I'm trying to > address something else. > In the future, it's possible some vendor will provide multiple mac > addresses with alone card that support multiple channel for tx/rx. That _is_ the case I'm talking about. The design review has happened, and the developer (Rajagopal Kunhappan) has running code that handles this case. He was easily able to implement this feature using the architecture proposed here. His gate is a child of mine, and he has implemented this as an additional address capability. He was involved in the design review for this work. What else can I say to you? This is a huge non-problem. > At > that time, how you set m_src_addr with multiple vendor-supplied addrs? With these cards, there is still one primary address used for stacks that don't support multiple MAC addresses. That's what's registered initially. When additional addresses are needed, a MAC capability is used to negotiate them. > This single unicast address in mac_register_t should not make sense. But yet it does, as additional unicast addresses can be negotiated using a capability. > As you descibed, m_dst_addr is optional. So why to open such obscure > optional interface to driver but not to move it to capability > negotiation? ;-) A unicast source address is not obscure. There is nothing architecturally wrong with optional registration information. >> Negotiate what? An initial minimum and maximum SDU needs to be >> specified, regardless of whether that changes. An additional MAC >> driver interface can be added in the future to _update_ the MTU (and >> I'm going to do that as part of the tunneling work in Clearview), but >> there's absolutely no case where a driver would have no MTU... > (to simplify the description, we'll use SDU is MTU without difference) > > This way was designed with GLDv2 or even older GLD version, it was > enough for nic drivers before JumboFrame is supported. JumboFrames are supported by GLDv2, and they are supported by GLDv3 _today_ before these changes. What exact problem are you addressing with this comment? > To ask every Ethernet driver to set m_max_sdu to 1500 is unnecessary, There is no such request in this proposal. > and that is lack of extension. > Indeed, to initiate a nic driver need two parameters of MTU, maximum MTU > and default MTU. The max_mtu is used to make sure the driver/nic is > configured with supported MTU, and the default MTU is used to initiate > the instance with appropriate size of tx/rx buffers and hardware > configuration. GLDv2 and Nemo are using max_sdu as default MTU, so the > way to enable Jumbo is not flexible enough. You could enable Jumbo through a capability. The capability could be MAC_CAPAB_JUMBO, and it could be negotiated at the time when the feature is enabled. There is still value in the driver supplying the initial value of max_sdu and min_sdu. > I'm sure the way need to be changed soon, but the first thing is to move > the interface out of mac_register_t to avoid further breaking binaries > compitibility. The suggested logic is: > * If the nic don't negotiatiate MTU. Set both max_mtu and > default_mtu to 1500 Why 1500? Why do you think that this number is appropriate? > * To enable Jumbo Frame, Driver need to negotiate the capability > with these informations: max_mtu, default_mtu, min_mtu Drivers don't initiate capability negotiations, the framework does. The only thing that is required in the common case is a "default", and there is _never_ a case when the framework can live without that information. A capability doesn't make sense as that default max_sdu is _always_ required. When and if Jumbo Frames are enabled, a capability could be used to negotiate additional values. There is no benefit to moving the default max_sdu into a capability. > The benefit of removing them from mac_register_t is this data structure > should only includ "soft" informations so that interface will be more > stable. There is nothing in this proposal that claims that the information that is supplied via mac_register_t can't change after registration. That's what the mac_*_update() functions are for. > With hardware evolving, any hardware capability is possibly > changed, so keep these "h/w related capabilities" in mac_register_t is > not better than negotiate them one by one. It's not hardware_register_t, it's mac_register_t. Values for max_sdu and min_sdu are required properties of a MAC by the framework. A MAC interface cannot function without them. Removing them from the mac_register_t is not helpful. > > I don't know what's the policy you decided to keeep which information in > mac_register_t and move which capability out. Capabilities are things that may or may not be supported by drivers (like JumboFrames). Information that is required of drivers in order for data-links of the given MAC-Type to operate (like a max_sdu and min_sdu) is in mac_register_t. > So I'd like to see that > *only s/w informations of the instance are included in mac_register_t*, > and "to negotiate all hardware capabilities with driver". :-) This is a a seemingly arbitrary request, as different driers associate different properties with hardware. For example, my IP tunneling driver has no hardware associated with it. -Seb From sacadmin Wed Apr 19 20:36:40 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3K3aeIQ008564 for ; Wed, 19 Apr 2006 20:36:40 -0700 (PDT) Received: from [129.146.108.78] (yagachi.SFBay.Sun.COM [129.146.108.78]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.6) with ESMTP id k3K3adPF265015; Wed, 19 Apr 2006 20:36:40 -0700 (PDT) Message-ID: <44470160.3010103@sun.com> Date: Wed, 19 Apr 2006 20:34:56 -0700 From: Rajagopal Kunhappan Reply-To: rajagopal.kunhappan@sun.com User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastien Roy CC: "Lu Yun-Song (Roamer)" , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, crossbow-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> <4446F46C.3060506@sun.com> In-Reply-To: <4446F46C.3060506@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1581 Sebastien Roy wrote: > Lu Yun-Song (Roamer) wrote: > >> I think I know the case you mentioned, that is to implement new >> interfaces to set multiple mac unicast addresses, but I'm trying to >> address something else. >> In the future, it's possible some vendor will provide multiple mac >> addresses with alone card that support multiple channel for tx/rx. > > > That _is_ the case I'm talking about. The design review has happened, > and the developer (Rajagopal Kunhappan) has running code that handles > this case. He was easily able to implement this feature using the > architecture proposed here. His gate is a child of mine, and he has > implemented this as an additional address capability. He was involved > in the design review for this work. What else can I say to you? This > is a huge non-problem. > >> At that time, how you set m_src_addr with multiple vendor-supplied >> addrs? > > > With these cards, there is still one primary address used for stacks > that don't support multiple MAC addresses. That's what's registered > initially. When additional addresses are needed, a MAC capability is > used to negotiate them. Roamer, Yes, what Seb says is right. Even with NICs that have multiple vendor supplied MAC addresses, there is one default/primary MAC address. The drivers that support multiple mac addresses will advertise it as a capability and clients wanting to use this feature will use mac_get_capab() and get the functions to access this feature. This case will come as soon as the timer expires on this one. Thanks, -krgopi From sacadmin Thu Apr 20 07:54:40 2006 Received: from sandieji.prc.sun.com (sandieji.PRC.Sun.COM [129.158.218.171]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3KEsdIQ009722 for ; Thu, 20 Apr 2006 07:54:39 -0700 (PDT) Received: from [129.158.218.199] (beyond [129.158.218.199]) by sandieji.prc.sun.com (8.13.2+Sun/8.13.2) with ESMTP id k3KEsb5e021568; Thu, 20 Apr 2006 22:54:37 +0800 (CST) Message-ID: <4447A0A6.4040801@sun.com> Date: Thu, 20 Apr 2006 22:54:30 +0800 From: "Lu Yun-Song (Roamer)" User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rajagopal.kunhappan@sun.com CC: Sebastien Roy , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, crossbow-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> <4446F46C.3060506@sun.com> <44470160.3010103@sun.com> In-Reply-To: <44470160.3010103@sun.com> Content-Type: multipart/alternative; boundary="------------050803070802020607010309" Status: RO Content-Length: 5624 This is a multi-part message in MIME format. --------------050803070802020607010309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Rajagopal Kunhappan wrote: >>> I think I know the case you mentioned, that is to implement new >>> interfaces to set multiple mac unicast addresses, but I'm trying to >>> address something else. >>> In the future, it's possible some vendor will provide multiple mac >>> addresses with alone card that support multiple channel for tx/rx. >> >> That _is_ the case I'm talking about. The design review has >> happened, and the developer (Rajagopal Kunhappan) has running code >> that handles this case. He was easily able to implement this feature >> using the architecture proposed here. His gate is a child of mine, >> and he has implemented this as an additional address capability. He >> was involved in the design review for this work. What else can I say >> to you? This is a huge non-problem. >> >>> At that time, how you set m_src_addr with multiple vendor-supplied >>> addrs? >> >> With these cards, there is still one primary address used for stacks >> that don't support multiple MAC addresses. That's what's registered >> initially. When additional addresses are needed, a MAC capability is >> used to negotiate them. > > Roamer, > > Yes, what Seb says is right. Even with NICs that have multiple vendor > supplied MAC > addresses, there is one default/primary MAC address. The drivers that > support > multiple mac addresses will advertise it as a capability and clients > wanting to use > this feature will use mac_get_capab() and get the functions to access > this feature. > This case will come as soon as the timer expires on this one. Krgopi/Seb, The current implementation is workable. My concern is this field in mac_register_t should be redundant when multiple vendor-supplied mac addresses are popular. And I think it's unnecessary to keep such capability in this data structure that should be very tidy. And I personal guess the assumption, there is one primary MAC address, should turn invalid over time. But it's not the best result if the mac_register_t would be putback with these definitely h/w capability information. Thanks, Roamer -- # /telnet +86-10-82618200 x82227/ Connected to OPG.Sun.COM. login: /Roamer.Lu@Sun.COM/ Last login: Mon Dec 22, 2003 from /beyond.prc/ Welcome! *Lu Yun-Song* [Roamer@Solaris Network]# --------------050803070802020607010309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rajagopal Kunhappan wrote:
I think I know the case you mentioned, that is to implement new interfaces to set multiple mac unicast addresses, but I'm trying to address something else.
In the future, it's possible some vendor will provide multiple mac addresses with alone card that support multiple channel for tx/rx.
That _is_ the case I'm talking about.  The design review has happened, and the developer (Rajagopal Kunhappan) has running code that handles this case.  He was easily able to implement this feature using the architecture proposed here.  His gate is a child of mine, and he has implemented this as an additional address capability.  He was involved in the design review for this work.  What else can I say to you?  This is a huge non-problem.
At that time, how you set m_src_addr with multiple vendor-supplied addrs?
With these cards, there is still one primary address used for stacks that don't support multiple MAC addresses.  That's what's registered initially.  When additional addresses are needed, a MAC capability is used to negotiate them.
Roamer,

Yes, what Seb says is right. Even with NICs that have multiple vendor supplied MAC
addresses, there is one default/primary MAC address. The drivers that support
multiple mac addresses will advertise it as a capability and clients wanting to use
this feature will use mac_get_capab() and get the functions to access this feature.
This case will come as soon as the timer expires on this one.
Krgopi/Seb,
The current implementation is workable. My concern is this field in mac_register_t should be redundant when multiple vendor-supplied mac addresses are popular. And I think it's unnecessary to keep such capability in this data structure that should be very tidy.

And I personal guess the assumption, there is one primary MAC address, should turn invalid over time.

But it's not the best result if the mac_register_t would be putback with these definitely h/w capability information.

Thanks,

Roamer
--

# telnet +86-10-82618200  x82227
Connected to OPG.Sun.COM.
login: Roamer.Lu@Sun.COM
Last login: Mon Dec 22, 2003 from beyond.prc
Welcome! Lu Yun-Song
[Roamer@Solaris Network]#




--------------050803070802020607010309-- From sacadmin Thu Apr 20 08:38:59 2006 Received: from sandieji.prc.sun.com (sandieji.PRC.Sun.COM [129.158.219.50]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3KFcwIQ011670 for ; Thu, 20 Apr 2006 08:38:59 -0700 (PDT) Received: from [129.158.218.199] (beyond [129.158.218.199]) by sandieji.prc.sun.com (8.13.2+Sun/8.13.2) with ESMTP id k3KFcvY1022360; Thu, 20 Apr 2006 23:38:57 +0800 (CST) Message-ID: <4447AB0A.30508@sun.com> Date: Thu, 20 Apr 2006 23:38:50 +0800 From: "Lu Yun-Song (Roamer)" User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastien Roy CC: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, crossbow-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> <4446F46C.3060506@sun.com> In-Reply-To: <4446F46C.3060506@sun.com> Content-Type: multipart/alternative; boundary="------------060509030002050001070206" Status: RO Content-Length: 13373 This is a multi-part message in MIME format. --------------060509030002050001070206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sebastien Roy wrote: >> At that time, how you set m_src_addr with multiple vendor-supplied >> addrs? > > > With these cards, there is still one primary address used for stacks > that don't support multiple MAC addresses. That's what's registered > initially. When additional addresses are needed, a MAC capability is > used to negotiate them. If a mac capability is used to negotiate additional mac addresses, how about to combine the negotiation with the field you put in mac_register_t? >> As you descibed, m_dst_addr is optional. So why to open such obscure >> optional interface to driver but not to move it to capability >> negotiation? ;-) > > A unicast source address is not obscure. There is nothing > architecturally wrong with optional registration information. How about to move *optional* informations to capability negotiation? Either way should work, but one way is more tidy than the other. :-P >> and that is lack of extension. >> Indeed, to initiate a nic driver need two parameters of MTU, maximum >> MTU and default MTU. The max_mtu is used to make sure the driver/nic >> is configured with supported MTU, and the default MTU is used to >> initiate the instance with appropriate size of tx/rx buffers and >> hardware configuration. GLDv2 and Nemo are using max_sdu as default >> MTU, so the way to enable Jumbo is not flexible enough. > > You could enable Jumbo through a capability. The capability could be > MAC_CAPAB_JUMBO, and it could be negotiated at the time when the > feature is enabled. There is still value in the driver supplying the > initial value of max_sdu and min_sdu. Can I rudely say the thought with Jumbo frame is out of date? Indeed, data link layer care only what's the current SDU/MTU. >> I'm sure the way need to be changed soon, but the first thing is to >> move the interface out of mac_register_t to avoid further breaking >> binaries compitibility. The suggested logic is: >> * If the nic don't negotiatiate MTU. Set both max_mtu and >> default_mtu to 1500 > > Why 1500? Why do you think that this number is appropriate? Do you think some other value should be appropriate for Ethernet adapter? GLD is Generic Lan Driver, such common feature should be limited in common code to make the interface simple. It's just like the goal of clearview. >> * To enable Jumbo Frame, Driver need to negotiate the capability >> with these informations: max_mtu, default_mtu, min_mtu > > Drivers don't initiate capability negotiations, the framework does. > The only thing that is required in the common case is a "default", and > there is _never_ a case when the framework can live without that > information. A capability doesn't make sense as that default max_sdu > is _always_ required. When and if Jumbo Frames are enabled, a > capability could be used to negotiate additional values. There is no > benefit to moving the default max_sdu into a capability. How about to forget Jumbo Frame and only care what's the max_mtu of MAC and what's the default mtu need to be configured? GLD should support WiFi media type, with which I think we don't need to regard 2K as jumbo frame comparing to 1500 at all. >> The benefit of removing them from mac_register_t is this data >> structure should only includ "soft" informations so that interface >> will be more stable. > > There is nothing in this proposal that claims that the information > that is supplied via mac_register_t can't change after registration. > That's what the mac_*_update() functions are for. Sorry, I said "more stable" for "no frequent changes to this data structure". >> With hardware evolving, any hardware capability is possibly changed, >> so keep these "h/w related capabilities" in mac_register_t is not >> better than negotiate them one by one. > > It's not hardware_register_t, it's mac_register_t. Values for max_sdu > and min_sdu are required properties of a MAC by the framework. A MAC > interface cannot function without them. Removing them from the > mac_register_t is not helpful. Yes, mac_register_t is not hardware_register_t. So it's better not to register hardware informations by it. If you can agree that 1500 can be used as default MTU for Ethernet, these two value should not be required properties any more. >> So I'd like to see that *only s/w informations of the instance are >> included in mac_register_t*, and "to negotiate all hardware >> capabilities with driver". :-) > > This is a a seemingly arbitrary request, as different driers associate > different properties with hardware. For example, my IP tunneling > driver has no hardware associated with it. So, let my change it to: * only s/w implementation of instance are included in mac_register_t, and * to negotiate all capabilities with driver. How about this simplified structure? typedef struct mac_register_s { uint_t m_version; const char *m_type_ident; void *m_driver; dev_info_t *m_dip; uint_t m_instance; mac_callbacks_t *m_callbacks; void *m_pdata; size_t m_pdata_size; } mac_register_t; * One new negotiation with driver is to find mac addresses. * One optional negotiation is to know whether this mac support different MTU size (compare to 1500). Thanks, Roamer -- # /telnet +86-10-82618200 x82227/ Connected to OPG.Sun.COM. login: /Roamer.Lu@Sun.COM/ Last login: Mon Dec 22, 2003 from /beyond.prc/ Welcome! *Lu Yun-Song* [Roamer@Solaris Network]# --------------060509030002050001070206 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sebastien Roy wrote:
At that time, how you set m_src_addr with multiple vendor-supplied addrs?

With these cards, there is still one primary address used for stacks that don't support multiple MAC addresses.  That's what's registered initially.  When additional addresses are needed, a MAC capability is used to negotiate them.
If a mac capability is used to negotiate additional mac addresses, how about to combine the negotiation with the field you put in mac_register_t?
As you descibed, m_dst_addr is optional. So why to open such obscure optional interface to driver but not to move it to capability negotiation? ;-)
A unicast source address is not obscure.  There is nothing architecturally wrong with optional registration information.
How about to move *optional* informations to capability negotiation? Either way should work, but one way is more tidy than the other. :-P
and that is lack of extension.
Indeed, to initiate a nic driver need two parameters of MTU, maximum MTU and default MTU. The max_mtu is used to make sure the driver/nic is configured with supported MTU, and the default MTU is used to initiate the instance with appropriate size of tx/rx buffers and hardware configuration. GLDv2 and Nemo are using max_sdu as default MTU, so the way to enable Jumbo is not flexible enough.
You could enable Jumbo through a capability.  The capability could be MAC_CAPAB_JUMBO, and it could be negotiated at the time when the feature is enabled.  There is still value in the driver supplying the initial value of max_sdu and min_sdu.
Can I rudely say the thought with Jumbo frame is out of date? Indeed, data link layer care only what's the current SDU/MTU.
I'm sure the way need to be changed soon, but the first thing is to move the interface out of mac_register_t to avoid further breaking binaries compitibility. The suggested logic is:
    * If the nic don't negotiatiate MTU. Set both max_mtu and default_mtu to 1500
Why 1500?  Why do you think that this number is appropriate?
Do you think some other value should be appropriate for Ethernet adapter? GLD is Generic Lan Driver, such common feature should be limited in common code to make the interface simple. It's just like the goal of clearview.
    * To enable Jumbo Frame, Driver need to negotiate the capability with these informations: max_mtu, default_mtu, min_mtu
Drivers don't initiate capability negotiations, the framework does.  The only thing that is required in the common case is a "default", and there is _never_ a case when the framework can live without that information.   A capability doesn't make sense as that default max_sdu is _always_ required.  When and if Jumbo Frames are enabled, a capability could be used to negotiate additional values.  There is no benefit to moving the default max_sdu into a capability.
How about to forget Jumbo Frame and only care what's the max_mtu of MAC and what's the default mtu need to be configured? GLD should support WiFi media type, with which I think we don't need to regard 2K as jumbo frame comparing to 1500 at all.
The benefit of removing them from mac_register_t is this data structure should only includ "soft" informations so that interface will be more stable.
There is nothing in this proposal that claims that the information that is supplied via mac_register_t can't change after registration.  That's what the mac_*_update() functions are for.
Sorry, I said "more stable" for "no frequent changes to this data structure".
With hardware evolving, any hardware capability is possibly changed, so keep these "h/w related capabilities" in mac_register_t is not better than negotiate them one by one.
It's not hardware_register_t, it's mac_register_t.  Values for max_sdu and min_sdu are required properties of a MAC by the framework.  A MAC interface cannot function without them.  Removing them from the mac_register_t is not helpful.
Yes, mac_register_t is not hardware_register_t. So it's better not to register hardware informations by it.

If you can agree that 1500 can be used as default MTU for Ethernet, these two value should not be required properties any more.
So I'd like to see that *only s/w informations of the instance are included in mac_register_t*, and "to negotiate all hardware capabilities with driver". :-)
This is a a seemingly arbitrary request, as different driers associate different properties with hardware.  For example, my IP tunneling driver has no hardware associated with it.
So, let my change it to:
    * only s/w implementation of instance are included in mac_register_t,   and
    * to negotiate all capabilities with driver.

How about this simplified structure?
typedef struct mac_register_s {
    uint_t        m_version;
    const char    *m_type_ident;
    void        *m_driver;
    dev_info_t    *m_dip;
    uint_t        m_instance;
    mac_callbacks_t *m_callbacks;
    void        *m_pdata;
    size_t        m_pdata_size;
} mac_register_t;

* One new negotiation with driver is to find mac addresses.
* One optional negotiation is to know whether this mac support different MTU size (compare to 1500).

Thanks,

Roamer

--

# telnet +86-10-82618200  x82227
Connected to OPG.Sun.COM.
login: Roamer.Lu@Sun.COM
Last login: Mon Dec 22, 2003 from beyond.prc
Welcome! Lu Yun-Song
[Roamer@Solaris Network]#




--------------060509030002050001070206-- From sacadmin Thu Apr 20 09:28:49 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.105]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3KGSnIQ014400 for ; Thu, 20 Apr 2006 09:28:49 -0700 (PDT) Received: from [129.146.11.214] (sr1-umpk-22.SFBay.Sun.COM [129.146.11.214]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.6) with ESMTP id k3KGSmAT853185; Thu, 20 Apr 2006 09:28:49 -0700 (PDT) Message-ID: <4447B6C0.1040805@Sun.COM> Date: Thu, 20 Apr 2006 09:28:48 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: "Lu Yun-Song (Roamer)" CC: Sebastien Roy , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM, crossbow-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> <4446F46C.3060506@sun.com> <4447AB0A.30508@sun.com> In-Reply-To: <4447AB0A.30508@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 327 Guys, may I suggest deferring the discussion of mutiple MAC addresses support to its own fast track: PSARC/2006/210 (Multiple unicast MAC addresses support), which is pending need spec new, and, as Raj said, will be filed shortly after this one (2006/249 Nemo Changes for Binary Compatibility) is approved, Thanks. Kais From sacadmin Thu Apr 20 09:33:18 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3KGXIIQ014579 for ; Thu, 20 Apr 2006 09:33:18 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IY1003014IK04@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Thu, 20 Apr 2006 12:33:17 -0400 (EDT) Received: from [129.148.174.103] (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IY100F2H4NHJ3@bur-mail2.east.sun.com>; Thu, 20 Apr 2006 12:33:17 -0400 (EDT) Date: Thu, 20 Apr 2006 12:33:17 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <4447AB0A.30508@sun.com> To: "Lu Yun-Song (Roamer)" Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, crossbow-iteam@sun.com Message-id: <4447B7CD.90707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060410) References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> <4446F46C.3060506@sun.com> <4447AB0A.30508@sun.com> Status: RO Content-Length: 2568 Lu Yun-Song (Roamer) wrote: > If a mac capability is used to negotiate additional mac addresses, how > about to combine the negotiation with the field you put in mac_register_t? No, because such negotiation would only happen when an external entity has a need for or configured additional addresses. Could you please refrain from designing the multi-mac-address feature on this list? >> A unicast source address is not obscure. There is nothing >> architecturally wrong with optional registration information. > How about to move *optional* informations to capability negotiation? > Either way should work, but one way is more tidy than the other. :-P No, and tidyness is not an architectural issue. Regardless, I don't agree that it's more tidy. Doing this would result in the mac module always calling back into drivers during every registration to get the unicast source address of the device. This is unecessary, as the primary unicast source can simply be supplied up front by the driver. The same goes for other optional information such as MAC plugin data (which you seem to feel is okay to be supplied in mac_register_t for some reason), the driver supplies this information up-front. There is no need to have the mac module call back into every driver to try and obtain that information through a capability when it can simply be provided up-front. > Can I rudely say the thought with Jumbo frame is out of date? Indeed, > data link layer care only what's the current SDU/MTU. Yes you can, and I completely agree. A clean implementation of Jumbo frames can be implemented using the proposed architecture without doing a capability negotiation. An initial max_sdu is needed, it needs to be provided by the driver, and the framework cannot assume that it's 1500 as you've suggested. If you don't understand that, then you've missed the point of this case and its dependent 2006/248. An externally triggered max_sdu change can be implemented any number of ways that are in-line with this architecture. One way is through a jumbogram capability negotiation. If that's not appropriate and is needlessly specific, then that's fine. Another way would be through a driver callback that changes the max_sdu. If the proposed max_sdu is outside the bounds of what the driver finds acceptable for the media, then it can reject the call. The driver could also modify its own max_sdu using a new MAC driver interface (say, mac_maxsdu_update()). Either way, an MTU capability is not needed (and doesn't make any sense). -Seb From sacadmin Thu Apr 20 18:13:53 2006 Received: from psyche.sfbay.sun.com (psyche.SFBay.Sun.COM [129.146.104.221]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3L1DrIQ004709 for ; Thu, 20 Apr 2006 18:13:53 -0700 (PDT) Received: from localhost (localhost [::1]) by psyche.sfbay.sun.com (8.11.7p1+Sun/8.11.7) with SMTP id k3L1BW821684; Thu, 20 Apr 2006 18:11:33 -0700 (PDT) X-Authentication-Warning: psyche.sfbay.sun.com: localhost [::1] didn't use HELO protocol Message-ID: <44483143.4030908@sun.com> Date: Thu, 20 Apr 2006 18:11:31 -0700 From: Eric Cheng User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040618 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastien Roy CC: "Lu Yun-Song (Roamer)" , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, crossbow-iteam@sun.com Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> <4446F46C.3060506@sun.com> <4447AB0A.30508@sun.com> <4447B7CD.90707@sun.com> In-Reply-To: <4447B7CD.90707@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1208 Sebastien Roy wrote: >> How about to move *optional* informations to capability negotiation? >> Either way should work, but one way is more tidy than the other. :-P > > No, and tidyness is not an architectural issue. Regardless, I don't > agree that it's more tidy. Doing this would result in the mac module > always calling back into drivers during every registration to get the > unicast source address of the device. This is unecessary, as the > primary unicast source can simply be > supplied up front by the driver. > Seb, sorry if this has already been discussed before. I think roamer was talking about the m_dst_addr field, which I believe, is only being used by your new tunnel driver, right? do you forsee any use of this for other mac drivers? I think roamer's concern (also mine) is that m_dst_addr is mac type specific and it's therefore unnatural to place it in mac_register_t. the only reason I see in favor of placing m_dst_addr in mac_register_t is that this will make your tunnel implementation cleaner -- i.e. you won't need to use two different mechanisms for getting at the src and dst addrs -- if this was your intention, I think it's ok to leave things as is. eric From sacadmin Thu Apr 20 21:15:25 2006 Received: from sandieji.prc.sun.com (sandieji.PRC.Sun.COM [129.158.219.52]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3L4FOIQ009847 for ; Thu, 20 Apr 2006 21:15:24 -0700 (PDT) Received: from [129.158.218.199] (beyond [129.158.218.199]) by sandieji.prc.sun.com (8.13.2+Sun/8.13.2) with ESMTP id k3L4FNUk008445; Fri, 21 Apr 2006 12:15:23 +0800 (CST) Message-ID: <44485C55.2050802@sun.com> Date: Fri, 21 Apr 2006 12:15:17 +0800 From: "Lu Yun-Song (Roamer)" User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kais Belgaied CC: Sebastien Roy , PSARC@sac.sfbay.sun.com, clearview-iteam@Sun.COM, crossbow-iteam@Sun.COM Subject: Re: 2006/249 Nemo Changes for Binary Compatibility References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> <4446F46C.3060506@sun.com> <4447AB0A.30508@sun.com> <4447B6C0.1040805@Sun.COM> In-Reply-To: <4447B6C0.1040805@Sun.COM> Content-Type: multipart/alternative; boundary="------------090306060705020206060509" Status: RO Content-Length: 2619 This is a multi-part message in MIME format. --------------090306060705020206060509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kais and Seb, Maybe I raised my concerns on wrong aliases. Sorry for it. I think I've expressed my concerns to this special data structure, and I'd better move the discussion off this alias. :-P Thanks, Roamer Kais Belgaied wrote: > Guys, > may I suggest deferring the discussion of mutiple MAC addresses > support to > its own fast track: PSARC/2006/210 (Multiple unicast MAC addresses > support), > which is pending need spec new, and, as Raj said, will be filed shortly > after this one (2006/249 Nemo Changes for Binary Compatibility) is > approved, > > Thanks. > > Kais > -- # /telnet +86-10-82618200 x82227/ Connected to OPG.Sun.COM. login: /Roamer.Lu@Sun.COM/ Last login: Mon Dec 22, 2003 from /beyond.prc/ Welcome! *Lu Yun-Song* [Roamer@Solaris Network]# --------------090306060705020206060509 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kais and Seb,
Maybe I raised my concerns on wrong aliases. Sorry for it.
I think I've expressed my concerns to this special data structure, and I'd better move the discussion off this alias. :-P

Thanks,

Roamer

Kais Belgaied wrote:
Guys,
may I suggest deferring the discussion of mutiple MAC addresses support to
its own fast track: PSARC/2006/210 (Multiple unicast MAC addresses support),
which is pending need spec new, and, as Raj said, will be filed shortly
after this one (2006/249 Nemo Changes for Binary Compatibility) is approved,

Thanks.

    Kais


--

# telnet +86-10-82618200  x82227
Connected to OPG.Sun.COM.
login: Roamer.Lu@Sun.COM
Last login: Mon Dec 22, 2003 from beyond.prc
Welcome! Lu Yun-Song
[Roamer@Solaris Network]#




--------------090306060705020206060509-- From sacadmin Thu Apr 20 22:13:13 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3L5DDIQ011770 for ; Thu, 20 Apr 2006 22:13:13 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IY200K013M8LG@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 21 Apr 2006 01:13:13 -0400 (EDT) Received: from [129.148.19.4] (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IY2008UN3TZVA@bur-mail2.east.sun.com>; Fri, 21 Apr 2006 01:13:13 -0400 (EDT) Date: Fri, 21 Apr 2006 01:12:46 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <44483143.4030908@sun.com> To: Eric Cheng Cc: "Lu Yun-Song (Roamer)" , PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com, crossbow-iteam@sun.com Message-id: <444869CE.1040408@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060410) References: <443EBE18.4040409@sun.com> <4446AC3B.4090407@sun.com> <4446AE26.7010505@sun.com> <4446E40F.7080103@sun.com> <4446F46C.3060506@sun.com> <4447AB0A.30508@sun.com> <4447B7CD.90707@sun.com> <44483143.4030908@sun.com> Status: RO Content-Length: 1385 Eric Cheng wrote: > sorry if this has already been discussed before. I think roamer was > talking about the m_dst_addr field, which I believe, is only being used > by your new tunnel driver, right? Yes, that's the only current driver that uses the field. > do you forsee any use of this for other mac drivers? Other types of tunneling drivers in the future may have a need for a fixed destination. > I think roamer's concern (also mine) is that > m_dst_addr is mac type specific and it's therefore unnatural to place it > in mac_register_t. It's not really a MAC-type specific property. The IP tunneling driver, for example, implements three different MAC-types (representing three different kinds of IP tunneling). Two of these have a need for a fixed destination handled by the framework, and one of them doesn't. > the only reason I see in favor of placing m_dst_addr > in mac_register_t is that this will make your tunnel implementation > cleaner -- i.e. you won't need to use two different mechanisms for > getting at the src and dst addrs -- if this was your intention, I think > it's ok to leave things as is. That's part of it. It does make the implementation cleaner, as the mac module doesn't need to always go and ask if the device supports a fixed destination on every registration (as it would need to do if this were a capability). Thanks, -Seb From sacadmin Fri Apr 21 07:00:20 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3LE0KIQ027865 for ; Fri, 21 Apr 2006 07:00:20 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IY200401S3ZA8@bur-mail2.east.sun.com> (original mail from sebastien.roy@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 21 Apr 2006 10:00:19 -0400 (EDT) Received: from [129.148.19.4] (punchin-seb.East.Sun.COM [129.148.19.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IY20087OS8IP2@bur-mail2.east.sun.com>; Fri, 21 Apr 2006 10:00:19 -0400 (EDT) Date: Fri, 21 Apr 2006 09:59:52 -0400 From: Sebastien Roy Subject: Re: 2006/249 Nemo Changes for Binary Compatibility In-reply-to: <443EBE18.4040409@sun.com> To: Sebastien Roy Cc: PSARC@sac.sfbay.sun.com, clearview-iteam@sun.com Message-id: <4448E558.8010501@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5 (X11/20060410) References: <443EBE18.4040409@sun.com> Status: RO Content-Length: 568 The timer on this fast-track has expired, and all issues have been resolved in a final spec which I have placed in the materials directory. I have marked it "closed approved." Here is a summary of what has changed in the spec since its original submission: - Fixed section 2.1 to correct the previously misleading description of m_version. - Specified possible error codes for mac_register() and mac_unregister(). - Minor modification to mac_pdata_update() to have it return an int. - Added a mac_capab_t enumerated type for MAC capabilities. Thanks, -Seb From sacadmin Wed Jun 21 13:52:37 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5LKqbJ1021232 for ; Wed, 21 Jun 2006 13:52:37 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5LKqbXT018121 for ; Wed, 21 Jun 2006 13:52:37 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5LKqbPG014370 for ; Wed, 21 Jun 2006 14:52:37 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J18000019IWTB00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 21 Jun 2006 14:52:37 -0600 (MDT) Received: from dhcp-ubur02-174-196.East.Sun.COM ([129.148.174.196]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1800C3S9ZOOI41@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Wed, 21 Jun 2006 14:52:37 -0600 (MDT) Date: Wed, 21 Jun 2006 16:52:36 -0400 From: Sebastien Roy Subject: 2006/249 minor spec updates prior to integration Sender: Sebastien.Roy@Sun.COM To: psarc Message-id: <1150923156.989.95.camel@strat.East.Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.2 Content-type: text/plain Content-transfer-encoding: 7BIT Status: RO Content-Length: 1354 The following self-reviewed modifications are being made to this case. I'll make the described updates to the spec in the materials directory. In section 4.2 "Modifications to Existing MAC Client Interfaces", the following subsections will be added, describing modifications to two Consolidation Private interfaces: 4.2.2 dls_create ---------------- int dls_create(const char *linkname, const char *macname, uint_t ddi_instance); In PSARC 2004/571, the second argument was described as the "driver instance name", and the third as the "m_port value" of the MAC associated with the new link. Because the new mac_register() mechanism described in section 2 does away with the concept of port numbers, the MAC is now described using its "MAC name" and the associated driver's DDI instance number. The MAC name is constructed by the mac module when a MAC registers using mac_register(). Its format is , where instance is either the DDI instance number of the registered DIP if m_instance is 0, or m_instance if m_instance is non-zero. The semantics of m_instance are described in section 2.1. 4.2.3 mac_open -------------- int mac_open(const char *macname, uint_t ddi_instance, mac_handle_t *mhp); The first two arguments of mac_open() are being modified similarly to dls_create(). -Seb From sacadmin Wed Jun 21 14:13:13 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5LLDD7H022210 for ; Wed, 21 Jun 2006 14:13:13 -0700 (PDT) Received: from [129.146.11.202] (sr1-umpk-18.SFBay.Sun.COM [129.146.11.202]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5LLDCoA416562; Wed, 21 Jun 2006 14:13:12 -0700 (PDT) Message-ID: <4499B668.8060407@Sun.COM> Date: Wed, 21 Jun 2006 14:13:12 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Sebastien Roy CC: psarc Subject: Re: 2006/249 minor spec updates prior to integration References: <1150923156.989.95.camel@strat.East.Sun.COM> In-Reply-To: <1150923156.989.95.camel@strat.East.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1912 you're saying that the ddi_instance argument is removed from both dls_create() and mac_open() since both take the macname as an argument, and since that macname inbeds the ddi_instance (it comes from the mac_register_t.m_instance) is there more to this change? it would be nice to see the prototype of the new version of the two functions changed (at least mac_open() since it is candidate for a more stable taxonomy promotion real soon) Kais Sebastien Roy wrote On 06/21/06 13:52,: >The following self-reviewed modifications are being made to this case. >I'll make the described updates to the spec in the materials >directory. > >In section 4.2 "Modifications to Existing MAC Client Interfaces", the >following subsections will be added, describing modifications to two >Consolidation Private interfaces: > > >4.2.2 dls_create >---------------- > > int dls_create(const char *linkname, const char *macname, > uint_t ddi_instance); > > > > In PSARC 2004/571, the second argument was described as the "driver > instance name", and the third as the "m_port value" of the MAC associated > with the new link. Because the new mac_register() mechanism described in > section 2 does away with the concept of port numbers, the MAC is now > described using its "MAC name" and the associated driver's DDI instance > number. > > The MAC name is constructed by the mac module when a MAC registers using > mac_register(). Its format is , where instance is > either the DDI instance number of the registered DIP if m_instance is 0, > or m_instance if m_instance is non-zero. The semantics of m_instance > are described in section 2.1. > >4.2.3 mac_open >-------------- > > int mac_open(const char *macname, uint_t ddi_instance, mac_handle_t *mhp); > > The first two arguments of mac_open() are being modified similarly to > dls_create(). > > > >-Seb > > > > From sacadmin Wed Jun 21 20:51:30 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5M3pU7t001284 for ; Wed, 21 Jun 2006 20:51:30 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k5M3pTJg019441 for ; Wed, 21 Jun 2006 20:51:29 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5M3pTn2005570 for ; Wed, 21 Jun 2006 21:51:29 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1800701RT4UR00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 21 Jun 2006 21:51:29 -0600 (MDT) Received: from punchin-seb.East.Sun.COM ([129.148.19.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J18002GZTDSFOP3@mail-amer.sun.com>; Wed, 21 Jun 2006 21:51:29 -0600 (MDT) Date: Wed, 21 Jun 2006 23:49:46 -0400 From: Sebastien Roy Subject: Re: 2006/249 minor spec updates prior to integration In-reply-to: <4499B668.8060407@Sun.COM> Sender: Sebastien.Roy@Sun.COM To: Kais Belgaied Cc: psarc Message-id: <1150948186.1739.9.camel@localhost> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.6.2 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1150923156.989.95.camel@strat.East.Sun.COM> <4499B668.8060407@Sun.COM> Status: RO Content-Length: 839 On Wed, 2006-06-21 at 14:13 -0700, Kais Belgaied wrote: > you're saying that the ddi_instance argument is removed from both > dls_create() and mac_open() since both take the macname as an argument, > and since > that macname inbeds the ddi_instance (it comes from the > mac_register_t.m_instance) No, maybe I wasn't clear; the function signatures don't change at all, but the semantics of the arguments do. The "driver" arguments change to be the MAC name, and the "port number" arguments change to be the DDI instance. The MAC name does not always embed DDI instance. For aggregations, the MAC name might be aggr5, but the DDI instance number is 0. Does that answer your question? > > it would be nice to see the prototype of the new version of the two > functions changed Yes, I included the prototypes in my message. -Seb From sacadmin Thu Jun 22 09:28:54 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MGSsTk022193 for ; Thu, 22 Jun 2006 09:28:54 -0700 (PDT) Received: from [129.146.11.202] (sr1-umpk-18.SFBay.Sun.COM [129.146.11.202]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5MGSspF941800; Thu, 22 Jun 2006 09:28:54 -0700 (PDT) Message-ID: <449AC545.8000202@Sun.COM> Date: Thu, 22 Jun 2006 09:28:53 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: Sebastien Roy CC: psarc Subject: Re: 2006/249 minor spec updates prior to integration References: <1150923156.989.95.camel@strat.East.Sun.COM> <4499B668.8060407@Sun.COM> <1150948186.1739.9.camel@localhost> In-Reply-To: <1150948186.1739.9.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 836 Sebastien Roy wrote On 06/21/06 20:49,: >On Wed, 2006-06-21 at 14:13 -0700, Kais Belgaied wrote: > > >>you're saying that the ddi_instance argument is removed from both >>dls_create() and mac_open() since both take the macname as an argument, >>and since >>that macname inbeds the ddi_instance (it comes from the >>mac_register_t.m_instance) >> >> > >No, maybe I wasn't clear; the function signatures don't change at all, >but the semantics of the arguments do. The "driver" arguments change to >be the MAC name, and the "port number" arguments change to be the DDI >instance. The MAC name does not always embed DDI instance. For >aggregations, the MAC name might be aggr5, but the DDI instance number >is 0. Does that answer your question? > > That answers my question. thanks for the clarification. Kais > >