From sacadmin Tue Mar 25 01:05:44 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2P85iW4003832; Tue, 25 Mar 2008 01:05:44 -0700 (PDT) Received: (from dr146992@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m2P85i9F003828; Tue, 25 Mar 2008 01:05:44 -0700 (PDT) Date: Tue, 25 Mar 2008 01:05:44 -0700 (PDT) From: Darren Reed Message-Id: <200803250805.m2P85i9F003828@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Committed API for packet interception [PSARC/2008/219 FastTrack timeout 04/01/2008] Status: RO Content-Length: 570 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Committed API for packet interception 1.2. Name of Document Author/Supplier: Author: Darren Reed 1.3 Date of This Document: 25 March, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Reed@sun.com Tue Mar 25 02:36:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2P9adou006389 for ; Tue, 25 Mar 2008 02:36:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2P9aUYX023356 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 25 Mar 2008 09:36:38 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYA004035D0A300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 25 Mar 2008 02:36:36 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYA00L6V5CYYXC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 25 Mar 2008 02:36:35 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2P9awX9009036 for ; Tue, 25 Mar 2008 09:36:58 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JYA00M015C1O500@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 25 Mar 2008 17:36:30 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYA006LL5CTKKZX@mail-apac.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 25 Mar 2008 17:36:30 +0800 (SGT) Date: Tue, 25 Mar 2008 02:36:32 -0700 From: Darren Reed Subject: PSARC/2008/219 Committed API for packet interception Sender: Darren.Reed@sun.com To: PSARC-EXT@sun.com Message-id: <47E8C7A0.1010609@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_mbOHzbrni/VJQlErriErKw)" X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 25967 This is a multi-part message in MIME format. --Boundary_(ID_mbOHzbrni/VJQlErriErKw) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT I'm submitting this case for myself as a fast track. --Boundary_(ID_mbOHzbrni/VJQlErriErKw) Content-type: text/plain; name=fulltext.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=fulltext.txt Abstract ======== This case seeks to expand on PSARC/2005/334, PSARC/2006/321 and PSARC/2007/666, evolving the APIs and presenting some of them as a committed interface. The key requirement that came out of this evolution is providing the means for multiple consumers of events to indicate that they are interested in receiving them. In addition, there is demand from the community for an interface that they are able to program to. Release Binding --------------- This case seeks to obtain approval for patch binding. Background ========== The first project to deliver packet filtering hooks into the mainline of IP processing, PSARC/2005/334, did so with an understanding that it would be limited to allowing a single consumer to process packets that it receives on a hook where the packet contents are allowed to be modified by definition of the hook. Since the completion of PSARC/2005/334 there has been widespread interest from various communities around both Solaris and OpenSolaris in seeing the API evolved further. Not long after the completion of this project, PSARC/2006/366 (IP instances) delivered into IP, providing the capability to define a local zone as having its own IP stack (routing table, TCP connections, etc.) As a part of this project, the hooks from PSARC/2005/334 were made local to each IP instance, so that a zone with a private instance of IP could choose whether or not to run a firewall, independant of the global zone and also with its own security policy. The result is that hooks now need some understanding of the instance of IP in which they are being used for them to be used with full meaning. Introduction ============ Boundaries ---------- This case is confined to dealing with the API that is exported via the netinfo (neti) module in the kernel. While this case will make it possible for consumers of the API to be aware of the different instances of IP that are active in the kernel, this project does not propose any sort of data management related to those instances: individual consumers of this API are responsible for managing their own instance data. Goals ----- This case seeks to accomplish the following major tasks: * provide an interface that allows consumsers to be aware of multiple IP instances; * provide an interface that allows multiple consumers of events to be present; * to provide a programatic method to specify the ordering of hooks, either relative to each other or as being first/last; * provide data management functions for objects used in relation to the APIs being introduced with this case; * document the observability being introduced through kstats. The new interfaces being introduced with this case are presented in a separate section below to that for the old interfaces being updated. More information (draft man pages) can be found in the case directory. Out of scope ------------ This case is concerned solely with the programming aspects behind using this API, not its management (through outside control). Thus the following is considered out of scope: * over-riding or otherwise managing the hook ordering hints that are (optionally) used by programmers. Interface changes from PSARC/2005/334 ===================================== This section walks through the changes to the previously introduced interfaces at a high level. See below for more technical detail on the changes. Naming changes. --------------- In reviewing the interfaces used in PSARC/2005/334, it became evident that the naming scheme used had not been well thought through for future work. The new naming style being pursued by this problem is, roughly speaking, net__(). There are also a few changes in the arguments to the functions. +-----------------------+-------------------------+ | PSARC/2005/334 | PSARC/2008/219 | |-----------------------+-------------------------+ | net_register | net_protocol_register | | net_unregister | net_protocol_unregister | | net_lookup | net_protocol_lookup | | net_release | net_protocol_release | | net_register_hook | net_hook_register | | net_unregister_hook | net_hook_unregister | | net_register_event | net_event_register | | net_unregister_event | net_event_unregister | | net_register_family | net_family_register | | net_unregister_family | net_family_unregister | | net_info_t | net_protocol_t | +-----------------------+-------------------------+ Table: Interface name changes +------------------------------+--------------------------------+ | PSARC/2005/334 | PSARC/2008/219 | |------------------------------+--------------------------------| | net_lookup(const char *) | net_protocol_lookup(netid_t, | | | const char *) | | net_walk(nat_data_t) | net_protocol_walk(netid_t, | | | net_data_t) | | net_register(net_info_t *) | net_protocol_register(netid_t, | | | const net_protocol_t *) | | net_routeto(net_data_t, | net_routeto(net_data_t, | | struct sockaddr *) | struct sockaddr *, | | | struct sockaddr *) | +------------------------------+--------------------------------+ Table: Interface changes from PSARC/2005/334 Data Structure changes ---------------------- This case promotes the use of structures involved with this API as being managed by this API, through the use of alloc/free functions. hook_t ~~~~~~ The use of this structure is now managed through hook_alloc() and hook_free(). Additions to this structure since PSARC/2005/334 include: * an ordering hint for the insertion of the hook on an event [h_hint]; * qualification data for the hint (such as a name) [h_hintvalue] and * an arbitrary argument to be passed back into the function called when the hook is activated by an event [h_arg]. net_inject_t ~~~~~~~~~~~~ This structure has been updated to include a version field, that is managed by this interface, with the change to using alloc/free functions. net_protocol_t ~~~~~~~~~~~~~~ This structure has been renamed from net_info_t in PSARC/2005/334 to a new name that better represents its purpose: to carry information through from a network protocol to the netinfo module. Accompanying the name change is an updating of all the field names for this structure. At present there is neither desire nor need to make it possible for code outside of this consolidation to register protocols, thus it the structure itself remains a private interface. hook_pkt_event_t ~~~~~~~~~~~~~~~~ An extra field has been added to the hook_pkt_event_t structure. The field, hpe_family, is provided to allow the function being called to use this (a net_data_t) value to discover the instance (and thereby zone) to which the event belongs. hook_nic_event_t ~~~~~~~~~~~~~~~~ As with hook_pkt_event_t, an extra field, hne_family, has been added to provide more context to the receiver of the event. New Interfaces ============== This case seeks to introduce some new interfaces, in addition to updating previously introduced interfaces. IP instance event notification ------------------------------ To provide the ability for consumers of this interface to become aware of the addition or removal of new IP stack instances to the live system, it is necessary to provide the consumer with the means to register a callback that is activated with related events. The means through which the callback is registered is via an allocated net_instance_t structure. This structure gives the consumer the ability to become informed of create, destroy and shutdown events. In registering callbacks, both the create and destroy must be supplied - a function to handle the shutdown callback is optional. See the interface table below for the respective commitment levels being sought. net_instance_t *net_instance_alloc(const int version); void net_instance_free(net_instance_t *); int net_instance_register(net_instance_t *); void net_instance_unregister(net_instance_t *); +----------------------------+-------------+ | Interface | Stability | +----------------------------+-------------+ | net_instance_alloc | Committed | | net_instance_free | Committed | | net_instance_register | Committed | | net_instance_unregister | Committed | | net_instance_t | Committed | +----------------------------+-------------+ Table: net_instance stability kstats ------ It is reasonable to expect that consumers of this interface may wish to publish information via kstats and thus may need to be able to provide different sets of data through kstats for each instance of the IP stack. Two new functions are introduced to create and destroy per instance kstat data. The returned pointer from net_kstat_create can be used with other kstat functions such as kstat_create. NOTE: The value returned from net_kstat_create must NOT be passed into kstat_delete and nor is the value returned from kstat_create allowed to be passed into net_kstat_delete. kstat_t *net_kstat_create(netid_t, char *, int, char *, char *, uchar_t, ulong_t, uchar_t); void net_kstat_delete(net_data_t, kstat_t *); +----------------------------+-------------+ | Interface | Stability | +----------------------------+-------------+ | net_kstat_create | Committed | | net_kstat_delete | Committed | +----------------------------+-------------+ Table: net kstat commitment Mapping instances to zones --------------------------- To map the network stack instance in which a hook is being executed to a zone and back again, two functions are supplied that convert zonid_t's to netid_t's and vice-versa. A zone that has an exclusive network stack instance will return a unique netid_t value for its given zoneid_t. The packet and network interface events that are provided by the netinfo framework come with a reference to the relevant protocol family by way of a net_data_t field. This can be mapped into a network stack identifier by using net_getnetid(). extern netid_t net_zoneidtonetid(zoneid_t); extern zoneid_t net_getzoneidbynetid(netid_t); extern netid_t net_getnetid(net_data_t); +-------------------------+------------+ | Interface | Commitment | +-------------------------+------------+ | net_getnetid | Committed | | net_getnetidbyzoneid | Committed | | net_getzoneidbynetid | Committed | +-------------------------+------------+ Table: Mapping netid_t/zoneid_t commitment Detailed Interface Specification For New Interfaces =================================================== Netinfo callbacks ----------------- The netinfo callback interface is provided to allow a consumer to become aware of when instances are created or destroyed. The definition of the structure can be found in section A.1. The fields are expected to be used as follows: * nin_version - used by the net_instance_*() functions and must not be modified by consumers; * nin_create - create function, must be set by consumer; * nin_destroy - destroy function, must be set by consumer; * nin_shutdown - shutdown function, must be set by consumer. The create function in the set of callbacks is called as a part of the process that creates a new instance of IP - before any traffic will appear for that instance. The only argument to the create function is an identifier that uniquely identifies this instance from all others. The return value from the create is passed back in as the 2nd argument to the destroy and shutdown functions. The destroy callback is called during the process of removing the owning instance of IP from the system. Hooks registered using the interface herein are expected to be unregistered through either the shutdown or destroy callback. The hook interface ------------------ The hook interface is provided as the means by which callbacks are added to an event that is provided by an event family. The structure to hold the hook information should be allocated by a call to hook_alloc() and when the owner is ready to free it, hook_free() should be called. The use of the data structure members is as follows: * h_version - initialised by hook_alloc() - must not be modified by consumer [PSARC/2005/334]; * h_func - function that the event should call [PSARC/2005/334]; * h_name - a text string representing the name given to this hook or owner of the hook [PSARC/2005/334]; * h_hint - hints about how to insert the hook on the event (see below for more details) [PSARC/2008/219]; * h_hintvalue - see the details below on hints for more information on how this field is to be used [PSARC/2008/219]; * h_arg - the value of h_arg is passed back into h_func as the 3rd argument to the callback function [PSARC/2008/219]. Hook hints ~~~~~~~~~~ A major problem with PSARC/2005/334 was that it limited each event to a single hook. This case proposes to remedy this limitation by allowing each hook to optionally specify a single *hint* about how it is placed on the list of hooks to call when an event is activated. There are 5 possible hints to choose from: * none (there are no special ordering constraints) * first (place the hook first) * last (place the hook last) * before "X" (place this hook before a hook named "X") * after "X" (place this hook after a hook named "X") A hook is limited to specifying only *1* hint for itself. For both of the hints specifying a hook should either be last (HH_LAST) or first (HH_FIRST), the h_hintvalue field in the hook structure should be 0. For both of these hints, only one hook may registered to an event with this hint. For the hints that specify before (HH_BEFORE) or after (HH_AFTER), the value of h_hintvalue should represent a pointer to a string for the name name of the other hook upon which the dependency will be asserted. The use of HH_AFTER with the name of a hook that has used HH_LAST will not succeed and likewise, using HH_BEFORE with the name of a hook that has specified the hint HH_FIRST will not succeed. The name supplied with HH_BEFORE/HH_AFTER may represent the name of a hook that is not currently present on the event, in which case, the hook is inserted on the event in a manner that will satisfy other hints present but is otherwise not deterministic. Example 1. If hook A is registered for event E first, and asks to be placed first on the list, then this will be done. If a later hook, B, is registered for event E, it may either ask to be placed before A or to be placed in the first position, but can only succeed in being placed after A. Adding hook A to event E: [E]--->[A(first)]--->| Adding hook B with the hint to be before A: [E]--->[A(first)]--->[B(after_A)]--->| The definition of the hint can be found in appendix A.2.2. Example 2. If hook A is registered for event E first (but without any hints), it is placed on the event hook list: [E]--->[A]--->| If I then add hook B and ask for it to be before A, the list of hooks becomes: [E]--->[B(before A)]--->[A]--->| If I follow this up with another hook C that wants to be before A, the end result can be either of the two following scenarios: [E]--->[C(before A)]--->[B(before A)]--->[A]--->| [E]--->[B(before A)]--->[C(before A)]--->[A]--->| IPFilter hook naming -------------------- For applications that wish to insert hooks before or after IPFilter in the packet stack, the names used by IPFilter are provided as an uncommitted interface: +------------------+--------------------------+----------------+ | Packet Hook | IPFilter Hook Name | Classification | +------------------+--------------------------+----------------+ | NH_PHYSICAL_IN | "ipfilter_hook_in" | Uncommitted | | NH_PHYSICAL_OUT | "ipfilter_hook_out" | Uncommitted | | NH_LOOPBACK_IN | "ipfilter_hook_loop_in" | Uncommitted | | NH_LOOPBACK_OUT | "ipfilter_hook_loop_out" | Uncommitted | +------------------+--------------------------+----------------+ kstats ====== To aid in diagnosing problems and system activity concerning the hooks, information is provided through the kstats interface concerning both events and the hooks registered to each event. When a hook event is registered with this framework, an entry is created in kstats that is associated with the relevant instance of IP. Similarly, whenever a hook is registered with a callback on an event, a kstat entry is automatically added for that too. When either hooks or hook events are removed, the respective entry in kstats is also removed. kstat naming ------------ Each hook event is represented in kstats as follows: module - hook family name ("inet", "inet6", etc) name - name of event ("PHYSICAL_IN", "PHYSICAL_OUT", etc) class - "hook_event" Three counters are published with each kstat in this group: hooksAdded - number of hooks registered with the event hooksRemoved - number of registered hooks removed events - count of the number of events executed Each hook registers a kstat node named as follows: module - family_name/event_name (ie. "inet/PHYSICAL_IN") name - hook name (ie. "ipfilter_hook_in") class - "hook" Six fields are published for each registered hook via kstats; version - value passed in to hook_alloc() flags - flags field from hook_t hint - ordering hint value hint_value - pointer associated with 'hint' (for HH_AFTER/BEFORE, the name is displayed) position - counter, starting at 1, reflecting the position of the hook for the event hook_hits - count of the number of times the callback is called To use the recorded kstats, it is possible to generate queries like this: ...to see all of the kstats for all hooks registered to all events: $ kstat -c hook ...to see all of the events registered to IPv6: $ kstat -m inet6 -c hook_event ...to see which events IPFilter has registered an inbound hook for: $ kstat -n ipfilter_hook_in -c hook Stability --------- The information and the provision of information via kstats is uncommited. Interfaces ========== +------------------------------------------+ | Interfaces Exported | +-------------------------+----------------+ | Interface | Classification | +-------------------------+----------------+ | hook_t | Committed | | hook_t | Committed | | hook_alloc | Committed | | hook_free | Committed | | hook_func_t | Committed | | hook_nic_event_t | Committed | | hook_pkt_event_t | Committed | | HOOK_VERSION | Committed | | GLOBAL_NETID | Committed | +-------------------------+----------------+ | netid_t | Committed | | net_instance_alloc | Committed | | net_instance_free | Committed | | net_instance_register | Committed | | net_instance_unregister | Committed | | net_instance_t | Committed | | net_event_register | Private | | net_event_unregister | Private | | net_family_register | Private | | net_family_unregister | Private | +-------------------------+----------------+ | net_getifname | Committed | | net_getmtu | Committed | | net_getnetid | Committed | | net_getpmtuenabled | Committed | | net_getlifaddr | Committed | | net_getzoneidbynetid | Committed | | net_hook_register | Committed | | net_hook_unregister | Committed | | net_inject | Committed | | net_inject_alloc | Committed | | net_inject_free | Committed | | net_inject_t | Committed | +-------------------------+----------------+ | net_ispartialchecksum | Committed | | net_isvalidchecksum | Committed | | net_kstat_create | Committed | | net_kstat_delete | Committed | | net_lifgetnext | Committed | | net_phygetnext | Committed | | net_phylookup | Committed | +-------------------------+----------------+ | net_protocol_lookup | Committed | | net_protocol_register | Private | | net_protocol_release | Committed | | net_protocol_unregister | Private | | net_protocol_walk | Private | | net_routeto | Committed | | net_zoneidtonetid | Committed | +-------------------------+----------------+ | NETINFO_VERSION | Committed | | NHF_ARP | Committed | | NHF_INET | Committed | | NHF_INET6 | Committed | | nic_event_t | Committed | | | Committed | | | Committed | | | Committed | +-------------------------+----------------+ | "ipfilter_hook_in" | Uncommitted | | "ipfilter_hook_out" | Uncommitted | | "ipfilter_hook_loop_in" | Uncommitted | | "ipfilter_hook_loop_out"| Uncommitted | +--------------------------+----------------+ Table: Exported interfaces stability Appendix A - Data structures ============================ A.1 - net_instance_t -------------------- typedef net_instance_s { int nin_version; char *nin_name; void *(*nin_create)(const netid_t); void (*nin_destroy)(const netid_t, void *); void (*nin_shutdown)(const netid_t, void *); } net_instance_t; A.2 - hook_t ------------ typedef struct hook { int h_version; hook_func_t h_func; char *h_name; hook_hint_t h_hint; uintptr_t h_hintvalue; void *h_arg; } hook_t; A.2.1 - hook_func_t ------------------- typedef int (* hook_func_t)(hook_event_token_t, hook_data_t, void *); A.2.2 - hook_hint_t ------------------- typedef enum hook_hint { HH_NONE = 0, HH_FIRST, HH_LAST, HH_BEFORE, HH_AFTER, } hook_hint_t; A.3 - net_inject_t ------------------ typedef struct net_inject { int ni_version; mblk_t *ni_packet; struct sockaddr_storage ni_addr; phy_if_t ni_physical; } net_inject_t; A.4 - hook_pkt_event_t ---------------------- typedef struct hook_pkt_event { net_data_t hpe_family; phy_if_t hpe_ifp; phy_if_t hpe_ofp; void *hpe_hdr; mblk_t **hpe_mp; mblk_t *hpe_mb; int hpe_flags; void *hpe_reserved[2]; } hook_pkt_event_t; A.5 - hook_nic_event_t ---------------------- typedef struct hook_nic_event { net_data_t hne_family; phy_if_t hne_nic; lif_if_t hne_lif; nic_event_t hne_event; nic_event_data_t hne_data; size_t hne_datalen; } hook_nic_event_t; A.5.1 - nic_event_t ------------------- typedef enum nic_event { NE_PLUMB = 1, NE_UNPLUMB, NE_UP, NE_DOWN, NE_ADDRESS_CHANGE } nic_event_t; B.5 - functions exported ------------------------ hook_t * hook_alloc(const int version) void hook_free(hook_t *) net_instance_t * net_instance_alloc(const int version); void net_instance_free(net_instance_t *); int net_instance_register(net_instance_t *); void net_instance_unregister(net_instance_t *); kstat_t * net_kstat_create(netid_t, char *, int, char *, char *, uchar_t, ulong_t, uchar_t); void net_kstat_delete(net_data_t, kstat_t *); net_inject_t * net_inject_alloc(const int); void net_inject_free(net_inject_t *); net_data_t net_protocol_lookup(netid_t, const char *); int net_protocol_release(net_data_t); int net_hook_register(net_data_t, char *, hook_t *); int net_hook_unregister(net_data_t, char *, hook_t *); int net_getifname(net_data_t, phy_if_t, char *, const size_t); int net_getmtu(net_data_t, phy_if_t, lif_if_t); typedef id_t netid_t; netid_t net_getnetid(net_data_t) int net_getpmtuenabled(net_data_t); int net_getlifaddr(net_data_t, phy_if_t, lif_if_t, int,; net_ifaddr_t [], void *); phy_if_t net_phygetnext(net_data_t, phy_if_t); phy_if_t net_phylookup(net_data_t, const char *); lif_if_t net_lifgetnext(net_data_t, phy_if_t, lif_if_t); int net_inject(net_data_t, inject_t, net_inject_t *); phy_if_t net_routeto(net_data_t, struct sockaddr *); int net_ispartialchecksum(net_data_t, mblk_t *); int net_isvalidchecksum(net_data_t, mblk_t *); Appendix B ========== The following table lists the netinfo functions that implement functionality that is also provided by socket ioctls. Socket ioctl netinfo function ----------------- ---------------- SIOCGLIFADDR net_getlifaddr() SIOCGLIFDSTADDR net_getlifaddr() SIOCGLIFBRDADDR net_getlifaddr() SIOCGLIFNETMASK net_getlifaddr() SIOCGLIFMTU net_getmtu() Appendix C ========== For illustrative purposes, source code has been included with this case and can be found in the case directory. The supplied sample file is a working example. --Boundary_(ID_mbOHzbrni/VJQlErriErKw)-- From erik.nordmark@sun.com Wed Mar 26 09:49:13 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QGnDd8000410 for ; Wed, 26 Mar 2008 09:49:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2QGnAb1000274; Wed, 26 Mar 2008 09:49:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYC00625K1YB900@nwk-avmta-2.sfbay.sun.com>; Wed, 26 Mar 2008 09:49:10 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.228.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYC0050LK1WV920@nwk-avmta-2.sfbay.sun.com>; Wed, 26 Mar 2008 09:49:08 -0700 (PDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QGn4JA870142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 09:49:04 -0700 (PDT) Date: Wed, 26 Mar 2008 09:48:59 -0700 From: Erik Nordmark Subject: Re: PSARC/2008/219 Committed API for packet interception In-reply-to: <47E8C7A0.1010609@Sun.COM> To: Darren Reed Cc: PSARC-EXT@sun.com Message-id: <47EA7E7B.7060003@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E8C7A0.1010609@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 2421 Darren Reed wrote: > I'm submitting this case for myself as a fast track. > Darren, I'm trying to figure out what assumptions are being made about the order that hook users and hook providers appear in the system. Looking at sample.c I see: static void sample_init(void) { ipv4 = net_protocol_lookup(GLOBAL_NETID, NHF_INET); Suppose the ISVs sample module somehow is loaded and initialized before /kernel/drv/ip. Then the above call would fail, because IP hasn't registered in with the netinfo framework. Since firewall like functionality (a potential user of the netinfo) wants to be in place before any IP packets can be sent and received, isn't it likely that the 3rd party sample module provider wants their module to load before IP? If they do, how does the module get notified when IP registers with the netinfo framework? I also have some issues with the description of things which I think affect the field names in the data structures as it relates to "family". As far as I understand family is the thing that can be either "inet" or "inet6". But the material has this text which is utterly confusing: > hook_pkt_event_t > ~~~~~~~~~~~~~~~~ > An extra field has been added to the hook_pkt_event_t structure. > The field, hpe_family, is provided to allow the function being called to > use this (a net_data_t) value to discover the instance (and thereby zone) > to which the event belongs. > > hook_nic_event_t > ~~~~~~~~~~~~~~~~ > As with hook_pkt_event_t, an extra field, hne_family, has been added to > provide more context to the receiver of the event. I don't see how a string like "inet" can be used to tell the difference between different IP instances. In fact the implementation due to hpe_family and hne_family being more than just a family - it is a net_data_t. Thus I think the above two fields should be renamed to something other than "family", and the description clarified. (I think the net_data_t is an opaque handle thus it might make sense to have "handle" in the name.) Finally an important terminology nit. We don't have anything called "stack instance" in Solaris. We have IP Instances used by exclusive-IP zones. Sticking to that terminology (which is more succinct than talking about "stacks") means that all occurances of "stack" in the document should be removed or replaced by "instance". (I can edit the document for this if you'd like.) Erik From Darren.Reed@sun.com Wed Mar 26 16:26:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QNQGFB019725 for ; Wed, 26 Mar 2008 16:26:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2QNQ7RY017794 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 27 Mar 2008 07:26:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYD00K192FR5100@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 26 Mar 2008 16:26:15 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYD00HI32FO2G30@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 26 Mar 2008 16:26:13 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2QNQasC007205 for ; Wed, 26 Mar 2008 23:26:36 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JYD005012A7DH00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 27 Mar 2008 07:26:08 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYD00JC22FJE7M6@mail-apac.sun.com>; Thu, 27 Mar 2008 07:26:08 +0800 (SGT) Date: Wed, 26 Mar 2008 16:26:10 -0700 From: Darren Reed Subject: Re: PSARC/2008/219 Committed API for packet interception In-reply-to: <47EA7E7B.7060003@sun.com> Sender: Darren.Reed@sun.com To: Erik Nordmark Cc: PSARC-EXT@sun.com Message-id: <47EADB92.8080700@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <47E8C7A0.1010609@Sun.COM> <47EA7E7B.7060003@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 3267 Erik Nordmark wrote: > Darren Reed wrote: > >> I'm submitting this case for myself as a fast track. >> > > Darren, > > I'm trying to figure out what assumptions are being made about the > order that hook users and hook providers appear in the system. > > Looking at sample.c I see: > > static void > sample_init(void) > { > ipv4 = net_protocol_lookup(GLOBAL_NETID, NHF_INET); > > > Suppose the ISVs sample module somehow is loaded and initialized > before /kernel/drv/ip. Then the above call would fail, because IP > hasn't registered in with the netinfo framework. > > Since firewall like functionality (a potential user of the netinfo) > wants to be in place before any IP packets can be sent and received, > isn't it likely that the 3rd party sample module provider wants their > module to load before IP? If they do, how does the module get notified > when IP registers with the netinfo framework? You've picked up on something I left out, which means I'll need to update the spec and resend. What I left out was providing the means to listen on and receive updates to: - protocols being added/removed - events being added/removed - hooks fpr events being added/removed > I also have some issues with the description of things which I think > affect the field names in the data structures as it relates to > "family". As far as I understand family is the thing that can be > either "inet" or "inet6". But the material has this text which is > utterly confusing: > >> hook_pkt_event_t >> ~~~~~~~~~~~~~~~~ >> An extra field has been added to the hook_pkt_event_t structure. >> The field, hpe_family, is provided to allow the function being called to >> use this (a net_data_t) value to discover the instance (and thereby >> zone) >> to which the event belongs. >> >> hook_nic_event_t >> ~~~~~~~~~~~~~~~~ >> As with hook_pkt_event_t, an extra field, hne_family, has been added to >> provide more context to the receiver of the event. > > > I don't see how a string like "inet" can be used to tell the > difference between different IP instances. > > In fact the implementation due to hpe_family and hne_family being more > than just a family - it is a net_data_t. Thus I think the above two > fields should be renamed to something other than "family", and the > description clarified. (I think the net_data_t is an opaque handle > thus it might make sense to have "handle" in the name.) I called it "family" because it relates to how the implementation fits together. If I sit back and look at, like you do, it does seem a rather bizarre choice of name given where it appears and how it is used. A better combination might be to use "net_handle_t" with "hne_protocol" and "hpe_protocol". > Finally an important terminology nit. We don't have anything called > "stack instance" in Solaris. We have IP Instances used by exclusive-IP > zones. Sticking to that terminology (which is more succinct than > talking about "stacks") means that all occurances of "stack" in the > document should be removed or replaced by "instance". (I can edit the > document for this if you'd like.) Yup, I understand that - the inclusion of the term "stack instance" was a mistake. I should have made a sweep over for that specifically. Darren From erik.nordmark@sun.com Thu Mar 27 09:53:51 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2RGrpbC018806 for ; Thu, 27 Mar 2008 09:53:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2RGrkus018526; Thu, 27 Mar 2008 09:53:49 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYE00F3NEXOTX00@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Mar 2008 09:53:48 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYE00CFYEXLDMB0@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Mar 2008 09:53:45 -0700 (PDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2RGri5d928885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 09:53:45 -0700 (PDT) Date: Thu, 27 Mar 2008 09:53:44 -0700 From: Erik Nordmark Subject: Re: PSARC/2008/219 Committed API for packet interception In-reply-to: <47EADB92.8080700@Sun.COM> To: Darren Reed Cc: PSARC-EXT@sun.com Message-id: <47EBD118.4040300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E8C7A0.1010609@Sun.COM> <47EA7E7B.7060003@sun.com> <47EADB92.8080700@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 1225 Darren Reed wrote: > You've picked up on something I left out, which means I'll need to > update the spec > and resend. > > What I left out was providing the means to listen on and receive updates > to: > - protocols being added/removed > - events being added/removed > - hooks fpr events being added/removed OK > I called it "family" because it relates to how the implementation fits > together. > > If I sit back and look at, like you do, it does seem a rather bizarre > choice of name > given where it appears and how it is used. > > A better combination might be to use "net_handle_t" with "hne_protocol" and > "hpe_protocol". Works for me. >> Finally an important terminology nit. We don't have anything called >> "stack instance" in Solaris. We have IP Instances used by exclusive-IP >> zones. Sticking to that terminology (which is more succinct than >> talking about "stacks") means that all occurances of "stack" in the >> document should be removed or replaced by "instance". (I can edit the >> document for this if you'd like.) > > > Yup, I understand that - the inclusion of the term "stack instance" was > a mistake. > I should have made a sweep over for that specifically. Thanks, Erik From Darren.Reed@sun.com Fri Mar 28 14:50:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2SLo3jj007574 for ; Fri, 28 Mar 2008 14:50:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2SLnx4I004146 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 29 Mar 2008 05:50:02 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYG0060BNBCQS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 28 Mar 2008 15:50:00 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYG00DZENBA0RE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 28 Mar 2008 15:50:00 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2SLoMqH011406 for ; Fri, 28 Mar 2008 21:50:22 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JYG00I01N5UVC00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 29 Mar 2008 05:49:55 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYG00J0ONB5C7VM@mail-apac.sun.com>; Sat, 29 Mar 2008 05:49:54 +0800 (SGT) Date: Fri, 28 Mar 2008 14:49:56 -0700 From: Darren Reed Subject: Re: PSARC/2008/219 Committed API for packet interception In-reply-to: <47EBD118.4040300@sun.com> Sender: Darren.Reed@sun.com To: Erik Nordmark Cc: PSARC-ext@sun.com Message-id: <47ED6804.9020601@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_PoKzG/Fj/7gE82HEJXwZag)" X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <47E8C7A0.1010609@Sun.COM> <47EA7E7B.7060003@sun.com> <47EADB92.8080700@Sun.COM> <47EBD118.4040300@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 29702 This is a multi-part message in MIME format. --Boundary_(ID_PoKzG/Fj/7gE82HEJXwZag) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Erik Nordmark wrote: > Darren Reed wrote: > >> You've picked up on something I left out, which means I'll need to >> update the spec >> and resend. >> >> What I left out was providing the means to listen on and receive >> updates to: >> - protocols being added/removed >> - events being added/removed >> - hooks fpr events being added/removed > > > OK Of these, the first (protocol addition/removal) is implied by the creation of a new IP instance. The other two require separate notification. I've updated the spec, to include the above and the other corrections. Darren --Boundary_(ID_PoKzG/Fj/7gE82HEJXwZag) Content-type: text/plain; name=fulltext.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=fulltext.txt Abstract ======== This case seeks to expand on PSARC/2005/334, PSARC/2006/321 and PSARC/2007/666, evolving the APIs and presenting some of them as a committed interface. The key requirement that came out of this evolution is providing the means for multiple consumers of events to indicate that they are interested in receiving them. In addition, there is demand from the community for an interface that they are able to program to. Release Binding --------------- This case seeks to obtain approval for patch binding. Background ========== The first project to deliver packet filtering hooks into the mainline of IP processing, PSARC/2005/334, did so with an understanding that it would be limited to allowing a single consumer to process packets that it receives on a hook where the packet contents are allowed to be modified by definition of the hook. Since the completion of PSARC/2005/334 there has been widespread interest from various communities around both Solaris and OpenSolaris in seeing the API evolved further. Not long after the completion of this project, PSARC/2006/366 (IP instances) delivered into IP, providing the capability to define a local zone as having its own IP stack (routing table, TCP connections, etc.) As a part of this project, the hooks from PSARC/2005/334 were made local to each IP instance, so that a zone with a private instance of IP could choose whether or not to run a firewall, independant of the global zone and also with its own security policy. The result is that hooks now need some understanding of the instance of IP in which they are being used for them to be used with full meaning. Introduction ============ Boundaries ---------- This case is confined to dealing with the API that is exported via the netinfo (neti) module in the kernel. While this case will make it possible for consumers of the API to be aware of the different instances of IP that are active in the kernel, this project does not propose any sort of data management related to those instances: individual consumers of this API are responsible for managing their own instance data. Goals ----- This case seeks to accomplish the following major tasks: * provide an interface that allows consumsers to be aware of multiple IP instances; * provide an interface that allows multiple consumers of events to be present; * to provide a programatic method to specify the ordering of hooks, either relative to each other or as being first/last; * provide data management functions for objects used in relation to the APIs being introduced with this case; * document the observability being introduced through kstats. The new interfaces being introduced with this case are presented in a separate section below to that for the old interfaces being updated. More information (draft man pages) can be found in the case directory. Out of scope ------------ This case is concerned solely with the programming aspects behind using this API, not its management (through outside control). Thus the following is considered out of scope: * over-riding or otherwise managing the hook ordering hints that are (optionally) used by programmers. Interface changes from PSARC/2005/334 ===================================== This section walks through the changes to the previously introduced interfaces at a high level. See below for more technical detail on the changes. Naming changes. --------------- In reviewing the interfaces used in PSARC/2005/334, it became evident that the naming scheme used had not been well thought through for future work. The new naming style being pursued by this problem is, roughly speaking, net__(). There are also a few changes in the arguments to the functions. +-----------------------+-------------------------+ | PSARC/2005/334 | PSARC/2008/219 | |-----------------------+-------------------------+ | net_register | net_protocol_register | | net_unregister | net_protocol_unregister | | net_lookup | net_protocol_lookup | | net_release | net_protocol_release | | net_register_hook | net_hook_register | | net_unregister_hook | net_hook_unregister | | net_register_event | net_event_register | | net_unregister_event | net_event_unregister | | net_register_family | net_family_register | | net_unregister_family | net_family_unregister | | net_info_t | net_protocol_t | +-----------------------+-------------------------+ Table: Interface name changes +------------------------------+--------------------------------+ | PSARC/2005/334 | PSARC/2008/219 | |------------------------------+--------------------------------| | net_lookup(const char *) | net_protocol_lookup(netid_t, | | | const char *) | | net_walk(nat_data_t) | net_protocol_walk(netid_t, | | | net_handle_t) | | net_register(net_info_t *) | net_protocol_register(netid_t, | | | const net_protocol_t *) | | net_routeto(net_handle_t, | net_routeto(net_handle_t, | | struct sockaddr *) | struct sockaddr *, | | | struct sockaddr *) | +------------------------------+--------------------------------+ Table: Interface changes from PSARC/2005/334 Data Structure changes ---------------------- This case promotes the use of structures involved with this API as being managed by this API, through the use of alloc/free functions. hook_t ~~~~~~ The use of this structure is now managed through hook_alloc() and hook_free(). Additions to this structure since PSARC/2005/334 include: * an ordering hint for the insertion of the hook on an event [h_hint]; * qualification data for the hint (such as a name) [h_hintvalue] and * an arbitrary argument to be passed back into the function called when the hook is activated by an event [h_arg]. net_inject_t ~~~~~~~~~~~~ This structure has been updated to include a version field, that is managed by this interface, with the change to using alloc/free functions. net_protocol_t ~~~~~~~~~~~~~~ This structure has been renamed from net_info_t in PSARC/2005/334 to a new name that better represents its purpose: to carry information through from a network protocol to the netinfo module. Accompanying the name change is an updating of all the field names for this structure. At present there is neither desire nor need to make it possible for code outside of this consolidation to register protocols, thus it the structure itself remains a private interface. hook_pkt_event_t ~~~~~~~~~~~~~~~~ An extra field has been added to the hook_pkt_event_t structure. The field, hpe_family, is provided to allow the function being called to use this (a net_handle_t) value to discover the instance (and thereby zone) to which the event belongs. hook_nic_event_t ~~~~~~~~~~~~~~~~ As with hook_pkt_event_t, an extra field, hne_family, has been added to provide more context to the receiver of the event. New Interfaces ============== This case seeks to introduce some new interfaces, in addition to updating previously introduced interfaces. IP instance event notification ------------------------------ To provide the ability for consumers of this interface to become aware of the addition or removal of new IP stack instances to the live system, it is necessary to provide the consumer with the means to register a callback that is activated with related events. The means through which the callback is registered is via an allocated net_instance_t structure. This structure gives the consumer the ability to become informed of create, destroy and shutdown events. In registering callbacks, both the create and destroy must be supplied - a function to handle the shutdown callback is optional. See the interface table below for the respective commitment levels being sought. +----------------------------+-------------+ | Interface | Stability | +----------------------------+-------------+ | net_instance_alloc | Committed | | net_instance_free | Committed | | net_instance_register | Committed | | net_instance_unregister | Committed | | net_instance_t | Committed | +----------------------------+-------------+ Table: net_instance stability Netinfo change notificactions ----------------------------- While the above callbacks provide notification of instances of IP as they arrive or schedule departure, there are two other sets of events that can be advantageous to become aware of - arrivial of events attached to a protocol and the callbacks registered on those events. The restrictions on the callbacks are minor: - they must not sleeping waiting for IO or user space; - they must not call net_*_notify_register or net_*_notify_unregister. +--------------------------------+----------------------------------+ | Target to monitor | Events received describe | +--------------------------------+----------------------------------+ | IP instance management | | | (net_instance_register | Addition/removal of IP instances | | net_instance_unregister) | | +--------------------------------+----------------------------------+ | Protocol event management | | | (net_protocol_notify_register | available for a protocol | | net_protocol_notify_unregister)| Addition/removal of events | +--------------------------------+----------------------------------+ | Hook callback management | | | (net_event_notify_register | Addition/removal of hooks to be | | net_event_notify_unregister) | called for protocol events | +--------------------------------+----------------------------------+ Table: API infrastructure change notifications +--------------------------------+-------------+ | Interface | Stability | +--------------------------------+-------------+ | net_event_notify_register | Committed | | net_event_notify_unregister | Committed | | net_protocol_notify_register | Committed | | net_protocol_notify_unregister | Committed | +--------------------------------+-------------+ Table: netinfo change notifications kstats ------ It is reasonable to expect that consumers of this interface may wish to publish information via kstats and thus may need to be able to provide different sets of data through kstats for each instance of the IP stack. Two new functions are introduced to create and destroy per instance kstat data. The returned pointer from net_kstat_create can be used with other kstat functions such as kstat_create. NOTE: The value returned from net_kstat_create must NOT be passed into kstat_delete and nor is the value returned from kstat_create allowed to be passed into net_kstat_delete. kstat_t *net_kstat_create(netid_t, char *, int, char *, char *, uchar_t, ulong_t, uchar_t); void net_kstat_delete(net_handle_t, kstat_t *); +----------------------------+-------------+ | Interface | Stability | +----------------------------+-------------+ | net_kstat_create | Committed | | net_kstat_delete | Committed | +----------------------------+-------------+ Table: net kstat commitment Mapping instances to zones --------------------------- To map the instance of IP in which a hook is being executed to z zone and back again, two functions are supplied that convert zonid_t's to netid_t's and vice-versa. A zone that has an exclusive network stack instance will return a unique netid_t value for its given zoneid_t. The packet and network interface events that are provided by the netinfo framework come with a reference to the relevant protocol family by way of a net_handle_t field. This can be mapped into an identifier that represents the instance of IP by using net_getnetid(). extern netid_t net_zoneidtonetid(zoneid_t); extern zoneid_t net_getzoneidbynetid(netid_t); extern netid_t net_getnetid(net_handle_t); +-------------------------+------------+ | Interface | Commitment | +-------------------------+------------+ | net_getnetid | Committed | | net_getnetidbyzoneid | Committed | | net_getzoneidbynetid | Committed | +-------------------------+------------+ Table: Mapping netid_t/zoneid_t commitment Detailed Interface Specification For New Interfaces =================================================== Netinfo callbacks ----------------- The netinfo callback interface is provided to allow a consumer to become aware of when instances are created or destroyed. The definition of the structure can be found in section A.1. The fields are expected to be used as follows: * nin_version - used by the net_instance_*() functions and must not be modified by consumers; * nin_create - create function, must be set by consumer; * nin_destroy - destroy function, must be set by consumer; * nin_shutdown - shutdown function, must be set by consumer. The create function in the set of callbacks is called as a part of the process that creates a new instance of IP - before any traffic will appear for that instance. The only argument to the create function is an identifier that uniquely identifies this instance from all others. The return value from the create is passed back in as the 2nd argument to the destroy and shutdown functions. The destroy callback is called during the process of removing the owning instance of IP from the system. Hooks registered using the interface herein are expected to be unregistered through either the shutdown or destroy callback. The hook interface ------------------ The hook interface is provided as the means by which callbacks are added to an event that is provided by an event family. The structure to hold the hook information should be allocated by a call to hook_alloc() and when the owner is ready to free it, hook_free() should be called. The use of the data structure members is as follows: * h_version - initialised by hook_alloc() - must not be modified by consumer [PSARC/2005/334]; * h_func - function that the event should call [PSARC/2005/334]; * h_name - a text string representing the name given to this hook or owner of the hook [PSARC/2005/334]; * h_hint - hints about how to insert the hook on the event (see below for more details) [PSARC/2008/219]; * h_hintvalue - see the details below on hints for more information on how this field is to be used [PSARC/2008/219]; * h_arg - the value of h_arg is passed back into h_func as the 3rd argument to the callback function [PSARC/2008/219]. Hook hints ~~~~~~~~~~ A major problem with PSARC/2005/334 was that it limited each event to a single hook. This case proposes to remedy this limitation by allowing each hook to optionally specify a single *hint* about how it is placed on the list of hooks to call when an event is activated. There are 5 possible hints to choose from: * none (there are no special ordering constraints) * first (place the hook first) * last (place the hook last) * before "X" (place this hook before a hook named "X") * after "X" (place this hook after a hook named "X") A hook is limited to specifying only *1* hint for itself. For both of the hints specifying a hook should either be last (HH_LAST) or first (HH_FIRST), the h_hintvalue field in the hook structure should be 0. For both of these hints, only one hook may registered to an event with this hint. For the hints that specify before (HH_BEFORE) or after (HH_AFTER), the value of h_hintvalue should represent a pointer to a string for the name name of the other hook upon which the dependency will be asserted. The use of HH_AFTER with the name of a hook that has used HH_LAST will not succeed and likewise, using HH_BEFORE with the name of a hook that has specified the hint HH_FIRST will not succeed. The name supplied with HH_BEFORE/HH_AFTER may represent the name of a hook that is not currently present on the event, in which case, the hook is inserted on the event in a manner that will satisfy other hints present but is otherwise not deterministic. Example 1. If hook A is registered for event E first, and asks to be placed first on the list, then this will be done. If a later hook, B, is registered for event E, it may either ask to be placed before A or to be placed in the first position, but can only succeed in being placed after A. Adding hook A to event E: [E]--->[A(first)]--->| Adding hook B with the hint to be before A: [E]--->[A(first)]--->[B(after_A)]--->| The definition of the hint can be found in appendix A.2.2. Example 2. If hook A is registered for event E first (but without any hints), it is placed on the event hook list: [E]--->[A]--->| If I then add hook B and ask for it to be before A, the list of hooks becomes: [E]--->[B(before A)]--->[A]--->| If I follow this up with another hook C that wants to be before A, the end result can be either of the two following scenarios: [E]--->[C(before A)]--->[B(before A)]--->[A]--->| [E]--->[B(before A)]--->[C(before A)]--->[A]--->| IPFilter hook naming -------------------- For applications that wish to insert hooks before or after IPFilter in the packet stack, the names used by IPFilter are provided as an uncommitted interface: +------------------+--------------------------+----------------+ | Packet Hook | IPFilter Hook Name | Classification | +------------------+--------------------------+----------------+ | NH_PHYSICAL_IN | "ipfilter_hook_in" | Uncommitted | | NH_PHYSICAL_OUT | "ipfilter_hook_out" | Uncommitted | | NH_LOOPBACK_IN | "ipfilter_hook_loop_in" | Uncommitted | | NH_LOOPBACK_OUT | "ipfilter_hook_loop_out" | Uncommitted | +------------------+--------------------------+----------------+ kstats ====== To aid in diagnosing problems and system activity concerning the hooks, information is provided through the kstats interface concerning both events and the hooks registered to each event. When a hook event is registered with this framework, an entry is created in kstats that is associated with the relevant instance of IP. Similarly, whenever a hook is registered with a callback on an event, a kstat entry is automatically added for that too. When either hooks or hook events are removed, the respective entry in kstats is also removed. kstat naming ------------ Each hook event is represented in kstats as follows: module - hook family name ("inet", "inet6", etc) name - name of event ("PHYSICAL_IN", "PHYSICAL_OUT", etc) class - "hook_event" Three counters are published with each kstat in this group: hooksAdded - number of hooks registered with the event hooksRemoved - number of registered hooks removed events - count of the number of events executed Each hook registers a kstat node named as follows: module - family_name/event_name (ie. "inet/PHYSICAL_IN") name - hook name (ie. "ipfilter_hook_in") class - "hook" Six fields are published for each registered hook via kstats; version - value passed in to hook_alloc() flags - flags field from hook_t hint - ordering hint value hint_value - pointer associated with 'hint' (for HH_AFTER/BEFORE, the name is displayed) position - counter, starting at 1, reflecting the position of the hook for the event hook_hits - count of the number of times the callback is called To use the recorded kstats, it is possible to generate queries like this: ...to see all of the kstats for all hooks registered to all events: $ kstat -c hook ...to see all of the events registered to IPv6: $ kstat -m inet6 -c hook_event ...to see which events IPFilter has registered an inbound hook for: $ kstat -n ipfilter_hook_in -c hook Stability --------- The information and the provision of information via kstats is uncommited. Interfaces ========== +-------------------------------------------------+ | Interfaces Exported | +--------------------------------+----------------+ | Interface | Classification | +--------------------------------+----------------+ | hook_t | Committed | | hook_alloc | Committed | | hook_free | Committed | | hook_func_t | Committed | | hook_nic_event_t | Committed | | hook_pkt_event_t | Committed | | HOOK_VERSION | Committed | | GLOBAL_NETID | Committed | +--------------------------------+----------------+ | netid_t | Committed | | net_instance_alloc | Committed | | net_instance_free | Committed | | net_instance_register | Committed | | net_instance_unregister | Committed | | net_instance_t | Committed | +--------------------------------+----------------+ | net_event_register | Private | | net_event_unregister | Private | | net_event_notify_register | Committed | | net_event_notify_unregister | Committed | | net_family_register | Private | | net_family_unregister | Private | +--------------------------------+----------------+ | net_getifname | Committed | | net_getmtu | Committed | | net_getnetid | Committed | | net_getpmtuenabled | Committed | | net_getlifaddr | Committed | | net_getzoneidbynetid | Committed | +--------------------------------+----------------+ | net_hook_register | Committed | | net_hook_unregister | Committed | | net_inject | Committed | | net_inject_alloc | Committed | | net_inject_free | Committed | | net_inject_t | Committed | +--------------------------------+----------------+ | net_ispartialchecksum | Committed | | net_isvalidchecksum | Committed | | net_kstat_create | Committed | | net_kstat_delete | Committed | | net_lifgetnext | Committed | | net_protocol_notify_register | Committed | | net_protocol_notify_unregister | Committed | | net_phygetnext | Committed | | net_phylookup | Committed | +--------------------------------+----------------+ | net_protocol_lookup | Committed | | net_protocol_notify_register | Committed | | net_protocol_notify_unregister | Committed | | net_protocol_register | Private | | net_protocol_release | Committed | | net_protocol_unregister | Private | | net_protocol_walk | Private | | net_routeto | Committed | | net_zoneidtonetid | Committed | +-------------------------------+----------------+ | NETINFO_VERSION | Committed | | NHF_ARP | Committed | | NHF_INET | Committed | | NHF_INET6 | Committed | | nic_event_t | Committed | | | Committed | | | Committed | | | Committed | +-------------------------------+----------------+ | "ipfilter_hook_in" | Uncommitted | | "ipfilter_hook_out" | Uncommitted | | "ipfilter_hook_loop_in" | Uncommitted | | "ipfilter_hook_loop_out" | Uncommitted | +--------------------------------+----------------+ Table: Exported interfaces stability Appendix A - Data structures ============================ A.1 - net_instance_t -------------------- typedef net_instance_s { int nin_version; char *nin_name; void *(*nin_create)(const netid_t); void (*nin_destroy)(const netid_t, void *); void (*nin_shutdown)(const netid_t, void *); } net_instance_t; A.2 - hook_t ------------ typedef struct hook { int h_version; hook_func_t h_func; char *h_name; hook_hint_t h_hint; uintptr_t h_hintvalue; void *h_arg; } hook_t; A.2.1 - hook_func_t ------------------- typedef int (* hook_func_t)(hook_event_token_t, hook_data_t, void *); A.2.2 - hook_hint_t ------------------- typedef enum hook_hint { HH_NONE = 0, HH_FIRST, HH_LAST, HH_BEFORE, HH_AFTER, } hook_hint_t; A.3 - net_inject_t ------------------ typedef struct net_inject { int ni_version; mblk_t *ni_packet; struct sockaddr_storage ni_addr; phy_if_t ni_physical; } net_inject_t; A.4 - hook_pkt_event_t ---------------------- typedef struct hook_pkt_event { net_handle_t hpe_protocol; phy_if_t hpe_ifp; phy_if_t hpe_ofp; void *hpe_hdr; mblk_t **hpe_mp; mblk_t *hpe_mb; int hpe_flags; void *hpe_reserved[2]; } hook_pkt_event_t; A.5 - hook_nic_event_t ---------------------- typedef struct hook_nic_event { net_handle_t hne_protocol; phy_if_t hne_nic; lif_if_t hne_lif; nic_event_t hne_event; nic_event_data_t hne_data; size_t hne_datalen; } hook_nic_event_t; A.5.1 - nic_event_t ------------------- typedef enum nic_event { NE_PLUMB = 1, NE_UNPLUMB, NE_UP, NE_DOWN, NE_ADDRESS_CHANGE } nic_event_t; B.5 - functions exported ------------------------ hook_t * hook_alloc(const int version) void hook_free(hook_t *) typedef int (* hook_notify_fn_t)(hook_notify_cmd_t, const char *, const char *, const char *); int net_event_notify_register(net_data_t family, char *event, hook_notify_fn_t callback); int net_event_notify_unregister(net_data_t family, char *event, hook_notify_fn_t callback); net_instance_t * net_instance_alloc(const int version); void net_instance_free(net_instance_t *); int net_instance_register(net_instance_t *); void net_instance_unregister(net_instance_t *); kstat_t * net_kstat_create(netid_t, char *, int, char *, char *, uchar_t, ulong_t, uchar_t); void net_kstat_delete(net_handle_t, kstat_t *); net_inject_t * net_inject_alloc(const int); void net_inject_free(net_inject_t *); net_handle_t net_protocol_lookup(netid_t, const char *); int net_protocol_release(net_handle_t); int net_hook_register(net_handle_t, char *, hook_t *); int net_hook_unregister(net_handle_t, char *, hook_t *); int net_getifname(net_handle_t, phy_if_t, char *, const size_t); int net_getmtu(net_handle_t, phy_if_t, lif_if_t); typedef id_t netid_t; netid_t net_getnetid(net_handle_t) int net_getpmtuenabled(net_handle_t); int net_getlifaddr(net_handle_t, phy_if_t, lif_if_t, int, net_ifaddr_t [], void *); lif_if_t net_lifgetnext(net_handle_t, phy_if_t, lif_if_t); int net_inject(net_handle_t, inject_t, net_inject_t *); phy_if_t net_phygetnext(net_handle_t, phy_if_t); phy_if_t net_phylookup(net_handle_t, const char *); int net_protocol_notify_register(net_data_t family, hook_notify_fn_t callback); int net_protocol_notify_unregister(net_data_t family, hook_notify_fn_t callback); phy_if_t net_routeto(net_handle_t, struct sockaddr *); int net_ispartialchecksum(net_handle_t, mblk_t *); int net_isvalidchecksum(net_handle_t, mblk_t *); Appendix B ========== The following table lists the netinfo functions that implement functionality that is also provided by socket ioctls. Socket ioctl netinfo function ----------------- ---------------- SIOCGLIFADDR net_getlifaddr() SIOCGLIFDSTADDR net_getlifaddr() SIOCGLIFBRDADDR net_getlifaddr() SIOCGLIFNETMASK net_getlifaddr() SIOCGLIFMTU net_getmtu() Appendix C ========== For illustrative purposes, source code has been included with this case and can be found in the case directory. The supplied sample file is a working example. --Boundary_(ID_PoKzG/Fj/7gE82HEJXwZag)-- From glenn.skinner@sun.com Fri Mar 28 15:23:35 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2SMNZx0008158 for ; Fri, 28 Mar 2008 15:23:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2SMNX6p007549; Fri, 28 Mar 2008 15:23:33 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYG00E1JOV8P900@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Mar 2008 15:23:32 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYG00BIYOV8KR30@nwk-avmta-2.sfbay.sun.com>; Fri, 28 Mar 2008 15:23:32 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m2SMNWs6003522; Fri, 28 Mar 2008 15:23:32 -0700 (PDT) Date: Fri, 28 Mar 2008 15:23:32 -0700 (PDT) From: Glenn Skinner Subject: Re: 2008/219 [Committed API for packet interception] To: Erik.Nordmark@sun.com, Darren.Reed@sun.com Cc: PSARC-ext@sun.com Reply-to: Glenn Skinner Message-id: <200803282223.m2SMNWs6003522@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: GPRagDlnLw2woan4uTsB/A== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1247 Date: Fri, 28 Mar 2008 14:49:56 -0700 From: Darren Reed Subject: Re: PSARC/2008/219 Committed API for packet interception ... I've updated the spec, to include the above and the other corrections. ... IPFilter hook naming -------------------- For applications that wish to insert hooks before or after IPFilter in the packet stack, the names used by IPFilter are provided as an uncommitted interface: +------------------+--------------------------+----------------+ | Packet Hook | IPFilter Hook Name | Classification | +------------------+--------------------------+----------------+ | NH_PHYSICAL_IN | "ipfilter_hook_in" | Uncommitted | | NH_PHYSICAL_OUT | "ipfilter_hook_out" | Uncommitted | | NH_LOOPBACK_IN | "ipfilter_hook_loop_in" | Uncommitted | | NH_LOOPBACK_OUT | "ipfilter_hook_loop_out" | Uncommitted | +------------------+--------------------------+----------------+ Does this case specify whether IPFilter supplies ordering hints when establishing its hooks? If so, what are they? (This would seem to be useful information for the applications alluded to above to know.) -- Glenn From Darren.Reed@Sun.COM Fri Mar 28 15:51:59 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2SMpwKZ009371 for ; Fri, 28 Mar 2008 15:51:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2SMpq2g001785; Fri, 28 Mar 2008 22:51:56 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYG00B09Q6JI900@brm-avmta-1.central.sun.com>; Fri, 28 Mar 2008 16:51:55 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYG0091CQ6IL820@brm-avmta-1.central.sun.com>; Fri, 28 Mar 2008 16:51:55 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2SMq4M9029015; Fri, 28 Mar 2008 22:52:04 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JYG00A01Q0YUH00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM); Sat, 29 Mar 2008 06:51:34 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYG00BQAQ5XMNUD@mail-apac.sun.com>; Sat, 29 Mar 2008 06:51:34 +0800 (SGT) Date: Fri, 28 Mar 2008 15:51:51 -0700 From: Darren Reed Subject: Re: 2008/219 [Committed API for packet interception] In-reply-to: <200803282223.m2SMNWs6003522@ivrel.sfbay.sun.com> Sender: Darren.Reed@Sun.COM To: Glenn Skinner Cc: PSARC-ext@Sun.COM Message-id: <47ED7687.8070909@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <200803282223.m2SMNWs6003522@ivrel.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1449 Glenn Skinner wrote: > Date: Fri, 28 Mar 2008 14:49:56 -0700 > From: Darren Reed > Subject: Re: PSARC/2008/219 Committed API for packet interception > > ... > I've updated the spec, to include the above and the other > corrections. > > ... > IPFilter hook naming > -------------------- > For applications that wish to insert hooks before or after IPFilter > in the packet stack, the names used by IPFilter are provided as an > uncommitted interface: > > +------------------+--------------------------+----------------+ > | Packet Hook | IPFilter Hook Name | Classification | > +------------------+--------------------------+----------------+ > | NH_PHYSICAL_IN | "ipfilter_hook_in" | Uncommitted | > | NH_PHYSICAL_OUT | "ipfilter_hook_out" | Uncommitted | > | NH_LOOPBACK_IN | "ipfilter_hook_loop_in" | Uncommitted | > | NH_LOOPBACK_OUT | "ipfilter_hook_loop_out" | Uncommitted | > +------------------+--------------------------+----------------+ > >Does this case specify whether IPFilter supplies ordering hints when >establishing its hooks? If so, what are they? (This would seem to be >useful information for the applications alluded to above to know.) > > As IPfilter does not make use of the ordering hints, there was nothing to mention...well, I suppose I should have mentioned that it doesn't use them. Darren From peter.memishian@sun.com Fri Mar 28 16:33:32 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2SNXWLa011165 for ; Fri, 28 Mar 2008 16:33:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2SNXVi9023898 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 28 Mar 2008 16:33:32 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYG00F0BS3U1100@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 28 Mar 2008 17:33:30 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYG0093HS3TL440@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 28 Mar 2008 17:33:30 -0600 (MDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2SNXRD9019296; Fri, 28 Mar 2008 19:33:27 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2SNXR1L931280; Fri, 28 Mar 2008 19:33:27 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2SNXRZG931210; Fri, 28 Mar 2008 19:33:27 -0400 (EDT) Date: Fri, 28 Mar 2008 19:33:27 -0400 From: Peter Memishian Subject: re: Committed API for packet interception [PSARC/2008/219 FastTrack timeout 04/01/2008] To: PSARC-ext@sun.com Cc: darren.reed@sun.com Reply-to: peter.memishian@sun.com Message-id: <18413.32839.460493.486897@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 857 A nit of sorts, but while we're making naming changes, could we phase out the "NIC" terminology in favor of "if" (for interface) throughout? For instance, the following is currently proposed: typedef enum nic_event { NE_PLUMB = 1, NE_UNPLUMB, NE_UP, NE_DOWN, NE_ADDRESS_CHANGE } nic_event_t; ... but this terminology is inconsistent with the rest of IP, which refers to [physical] interfaces being plumbed/unplumbed, [physical or logical] interfaces being brought up/down, and [logical] interfaces changing addresses. It seems that this has already been done for some of the functions (e.g., net_getifname() is proposed rather than net_getnicname()) but it'd be nice if this could be made more uniform. Alternatively, if there's a justification for the current terminology split, I'm all ears. -- meem From peter.memishian@sun.com Tue Apr 8 17:15:33 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m390FWDs020211 for ; Tue, 8 Apr 2008 17:15:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m390FUpQ017114 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 Apr 2008 01:15:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ100M077DTM600@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 08 Apr 2008 17:15:29 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ100DB47DSJOD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 08 Apr 2008 17:15:29 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m390FQ9U008480; Tue, 08 Apr 2008 20:15:26 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m390FQpT560159; Tue, 08 Apr 2008 20:15:26 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m390FQwf560156; Tue, 08 Apr 2008 20:15:26 -0400 (EDT) Date: Tue, 08 Apr 2008 20:15:26 -0400 From: Peter Memishian Subject: Committed API for packet interception [PSARC/2008/219 FastTrack timeout 04/01/2008] To: psarc-ext@sun.com Cc: darren.reed@sun.com Reply-to: peter.memishian@sun.com Message-id: <18428.2718.499034.2699@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 94 I see this case has been marked approved without any response to my comments. Why? -- meem From Darren.Reed@sun.com Thu Apr 10 14:58:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3ALw0lm018361 for ; Thu, 10 Apr 2008 14:58:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3ALvs1R007346 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 11 Apr 2008 05:57:59 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ400M01QCKQJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 10 Apr 2008 14:57:56 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ400L92QCIEM20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 10 Apr 2008 14:57:55 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3ALwOFB006857 for ; Thu, 10 Apr 2008 21:58:24 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZ400I01Q6GAI00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 11 Apr 2008 05:57:47 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ4004TCQCAPGLO@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 11 Apr 2008 05:57:47 +0800 (SGT) Date: Thu, 10 Apr 2008 14:57:52 -0700 From: Darren Reed Subject: Re: Committed API for packet interception [PSARC/2008/219 FastTrack timeout 04/01/2008] In-reply-to: <18413.32839.460493.486897@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: PSARC-ext@sun.com Message-id: <47FE8D60.9030907@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <18413.32839.460493.486897@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1588 > > >A nit of sorts, but while we're making naming changes, could we phase out >the "NIC" terminology in favor of "if" (for interface) throughout? For >instance, the following is currently proposed: > > typedef enum nic_event { > NE_PLUMB = 1, > NE_UNPLUMB, > NE_UP, > NE_DOWN, > NE_ADDRESS_CHANGE > } nic_event_t; > >... but this terminology is inconsistent with the rest of IP, which refers >to [physical] interfaces being plumbed/unplumbed, [physical or logical] >interfaces being brought up/down, and [logical] interfaces changing >addresses. > >It seems that this has already been done for some of the functions (e.g., >net_getifname() is proposed rather than net_getnicname()) but it'd be >nice if this could be made more uniform. > >Alternatively, if there's a justification for the current terminology >split, I'm all ears. > > When considering what other names were available, all of them appeared to be just as bad, if not worse: if_event_t, nif_event_t, something_event_t. While the naming may not be in alignment with other names, nic_event_t doesn't seem to suffer as badly. In the case of the function calls, the "ifname" is qualified by the net_ at the front. So, as a "nit", I accept and understand the criticism but I don't feel that there are any other names that work as well without some other penalty. But the comment above is just that - a nit. Maybe not everyone likes the colour of this bike shed (that's to be expected), but I'm happy with it and it doesn't seem to be too offensive, all things considered. Darren From Darren.Reed@sun.com Thu Apr 10 14:58:08 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3ALw72a018373 for ; Thu, 10 Apr 2008 14:58:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3ALw1hY000708 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 10 Apr 2008 22:58:06 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ400417QCS6700@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Apr 2008 15:58:04 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ400JJZQCPA960@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Apr 2008 15:58:02 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3ALwDLc014260 for ; Thu, 10 Apr 2008 21:58:13 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZ400K01Q84WB00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 11 Apr 2008 05:57:26 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ400BFAQBPRFFH@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 11 Apr 2008 05:57:26 +0800 (SGT) Date: Thu, 10 Apr 2008 14:57:59 -0700 From: Darren Reed Subject: Re: PSARC/2008/219 Committed API for packet interception Sender: Darren.Reed@sun.com To: PSARC-EXT Message-id: <47FE8D67.3000609@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 61 This case was closed and approved on the 2nd of April 2008. From peter.memishian@sun.com Thu Apr 10 17:55:47 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3B0tlJg023898 for ; Thu, 10 Apr 2008 17:55:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3B0tlCo029938 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 10 Apr 2008 17:55:47 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ400F01YKZQH00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Apr 2008 18:55:47 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ400DD2YKYE810@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Apr 2008 18:55:46 -0600 (MDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3B0thI2015145; Thu, 10 Apr 2008 20:55:43 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3B0th03444528; Thu, 10 Apr 2008 20:55:43 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m3B0thd1444483; Thu, 10 Apr 2008 20:55:43 -0400 (EDT) Date: Thu, 10 Apr 2008 20:55:42 -0400 From: Peter Memishian Subject: Re: Committed API for packet interception [PSARC/2008/219 FastTrack Re: Committed API for packet interception [PSARC/2008/219 FastTrack To: PSARC-ext@sun.com, darren.reed@sun.com Reply-to: peter.memishian@sun.com Message-id: <18430.46862.984547.298531@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 475 > When considering what other names were available, all of them appeared to > be just as bad, if not worse: if_event_t, nif_event_t, > something_event_t. What would be wrong with net_if_event_t? Seems in keeping with the rest of the nomenclature. My issue is one of consistency: we already consistently use "interface" for this purpose throughout IP. Using "NIC" just creates confusion, and we'll be stuck with this wart forever once this API is committed. -- meem From peter.memishian@sun.com Thu Apr 10 17:55:47 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3B0tlJg023898 for ; Thu, 10 Apr 2008 17:55:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m3B0tlCo029938 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 10 Apr 2008 17:55:47 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ400F01YKZQH00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Apr 2008 18:55:47 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ400DD2YKYE810@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Apr 2008 18:55:46 -0600 (MDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3B0thI2015145; Thu, 10 Apr 2008 20:55:43 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3B0th03444528; Thu, 10 Apr 2008 20:55:43 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m3B0thd1444483; Thu, 10 Apr 2008 20:55:43 -0400 (EDT) Date: Thu, 10 Apr 2008 20:55:42 -0400 From: Peter Memishian Subject: Re: Committed API for packet interception [PSARC/2008/219 FastTrack Re: Committed API for packet interception [PSARC/2008/219 FastTrack To: PSARC-ext@sun.com, darren.reed@sun.com Reply-to: peter.memishian@sun.com Message-id: <18430.46862.984547.298531@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 475 > When considering what other names were available, all of them appeared to > be just as bad, if not worse: if_event_t, nif_event_t, > something_event_t. What would be wrong with net_if_event_t? Seems in keeping with the rest of the nomenclature. My issue is one of consistency: we already consistently use "interface" for this purpose throughout IP. Using "NIC" just creates confusion, and we'll be stuck with this wart forever once this API is committed. -- meem From Darren.Reed@Sun.COM Thu Apr 10 18:05:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3B15f3o024051 for ; Thu, 10 Apr 2008 18:05:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3B15eiT010832 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 11 Apr 2008 02:05:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ400L07Z1GDF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 10 Apr 2008 18:05:40 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ400IDHZ1EF830@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 10 Apr 2008 18:05:39 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3B15oZb020575 for ; Fri, 11 Apr 2008 01:05:50 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZ400001Z0WHM00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 11 Apr 2008 09:05:30 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ40044ZZ15PGGP@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 11 Apr 2008 09:05:30 +0800 (SGT) Date: Thu, 10 Apr 2008 18:05:36 -0700 From: Darren Reed Subject: Re: Committed API for packet interception [PSARC/2008/219 FastTrack Re: Committed API for packet interception [PSARC/2008/219 FastTrack In-reply-to: <18430.46862.984547.298531@gargle.gargle.HOWL> Sender: Darren.Reed@Sun.COM To: PSARC-ext@Sun.COM Message-id: <47FEB960.9050606@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <18430.46862.984547.298531@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 696 Peter Memishian wrote: > > When considering what other names were available, all of them appeared to > > be just as bad, if not worse: if_event_t, nif_event_t, > > something_event_t. > >What would be wrong with net_if_event_t? Seems in keeping with the rest >of the nomenclature. > >My issue is one of consistency: we already consistently use "interface" >for this purpose throughout IP. Using "NIC" just creates confusion, and >we'll be stuck with this wart forever once this API is committed. > > > I'll repeat... Maybe not everyone likes the colour of this bike shed (that's to be expected), but I'm happy with it and it doesn't seem to be too offensive, all things considered. Darren From Darren.Reed@Sun.COM Thu Apr 10 18:05:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3B15f3o024051 for ; Thu, 10 Apr 2008 18:05:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3B15eiT010832 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 11 Apr 2008 02:05:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ400L07Z1GDF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 10 Apr 2008 18:05:40 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ400IDHZ1EF830@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 10 Apr 2008 18:05:39 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3B15oZb020575 for ; Fri, 11 Apr 2008 01:05:50 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZ400001Z0WHM00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 11 Apr 2008 09:05:30 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZ40044ZZ15PGGP@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 11 Apr 2008 09:05:30 +0800 (SGT) Date: Thu, 10 Apr 2008 18:05:36 -0700 From: Darren Reed Subject: Re: Committed API for packet interception [PSARC/2008/219 FastTrack Re: Committed API for packet interception [PSARC/2008/219 FastTrack In-reply-to: <18430.46862.984547.298531@gargle.gargle.HOWL> Sender: Darren.Reed@Sun.COM To: PSARC-ext@Sun.COM Message-id: <47FEB960.9050606@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <18430.46862.984547.298531@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 696 Peter Memishian wrote: > > When considering what other names were available, all of them appeared to > > be just as bad, if not worse: if_event_t, nif_event_t, > > something_event_t. > >What would be wrong with net_if_event_t? Seems in keeping with the rest >of the nomenclature. > >My issue is one of consistency: we already consistently use "interface" >for this purpose throughout IP. Using "NIC" just creates confusion, and >we'll be stuck with this wart forever once this API is committed. > > > I'll repeat... Maybe not everyone likes the colour of this bike shed (that's to be expected), but I'm happy with it and it doesn't seem to be too offensive, all things considered. Darren From erik.nordmark@sun.com Fri Apr 11 13:43:12 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3BKhBXP024067 for ; Fri, 11 Apr 2008 13:43:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3BKh1i7018605; Sat, 12 Apr 2008 04:43:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ600M1DHJSAR00@nwk-avmta-2.sfbay.sun.com>; Fri, 11 Apr 2008 13:43:04 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.106.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ600IUKHJRQ940@nwk-avmta-2.sfbay.sun.com>; Fri, 11 Apr 2008 13:43:03 -0700 (PDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3BKgulW371239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 13:42:57 -0700 (PDT) Date: Fri, 11 Apr 2008 13:42:56 -0700 From: Erik Nordmark Subject: Re: PSARC/2008/219 Committed API for packet interception In-reply-to: <47ED6804.9020601@Sun.COM> To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <47FFCD50.5090102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E8C7A0.1010609@Sun.COM> <47EA7E7B.7060003@sun.com> <47EADB92.8080700@Sun.COM> <47EBD118.4040300@sun.com> <47ED6804.9020601@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 904 Darren Reed wrote: > Erik Nordmark wrote: > >> Darren Reed wrote: >> >>> You've picked up on something I left out, which means I'll need to >>> update the spec >>> and resend. >>> >>> What I left out was providing the means to listen on and receive >>> updates to: >>> - protocols being added/removed >>> - events being added/removed >>> - hooks fpr events being added/removed >> >> >> OK > > > Of these, the first (protocol addition/removal) is implied by > the creation of a new IP instance. The other two require > separate notification. That assumes all protocols are up and running in the kernel before the first interested consumer. Do we know that is the case? > I've updated the spec, to include the above and the other > corrections. Your updated spec has a net_protocol_notify_register(), hence I do think you cover what is needed. But your comment above is confusing me. Eriik From Darren.Reed@sun.com Wed Apr 16 02:57:39 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3G9vcTj002083 for ; Wed, 16 Apr 2008 02:57:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m3G9vXUA007910 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 16 Apr 2008 17:57:38 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZE00K0DWZXOZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Apr 2008 02:57:33 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZE00GIGWZWU850@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Apr 2008 02:57:33 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3G9w4q1009114 for ; Wed, 16 Apr 2008 09:58:04 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JZE00201WF9C200@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Apr 2008 17:56:52 +0800 (SGT) Received: from [129.158.219.238] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZE00B54WYPREIE@mail-apac.sun.com>; Wed, 16 Apr 2008 17:56:50 +0800 (SGT) Date: Wed, 16 Apr 2008 02:57:23 -0700 From: Darren Reed Subject: Re: PSARC/2008/219 Committed API for packet interception In-reply-to: <47FFCD50.5090102@sun.com> Sender: Darren.Reed@sun.com To: Erik Nordmark Cc: PSARC-ext@sun.com Message-id: <4805CD83.6080100@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E8C7A0.1010609@Sun.COM> <47EA7E7B.7060003@sun.com> <47EADB92.8080700@Sun.COM> <47EBD118.4040300@sun.com> <47ED6804.9020601@Sun.COM> <47FFCD50.5090102@sun.com> User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) Status: RO Content-Length: 939 Erik Nordmark wrote: > Darren Reed wrote: >> Erik Nordmark wrote: >> >>> Darren Reed wrote: >>> >>>> You've picked up on something I left out, which means I'll need to >>>> update the spec >>>> and resend. >>>> >>>> What I left out was providing the means to listen on and receive >>>> updates to: >>>> - protocols being added/removed >>>> - events being added/removed >>>> - hooks fpr events being added/removed >>> >>> >>> OK >> >> >> Of these, the first (protocol addition/removal) is implied by >> the creation of a new IP instance. The other two require >> separate notification. > > That assumes all protocols are up and running in the kernel before the > first interested consumer. Do we know that is the case? What I think you're missing is that all instances of a protocol are to be announced via the net_instance_* mechanism, not just those that are created at run time as zones with exclusive instances are added. Darren From erik.nordmark@sun.com Wed Apr 16 09:34:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3GGYQrM013590 for ; Wed, 16 Apr 2008 09:34:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m3GGY7JL018262; Wed, 16 Apr 2008 17:34:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZF00D01FD9CA00@nwk-avmta-2.sfbay.sun.com>; Wed, 16 Apr 2008 09:34:21 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZF009NJFD9RC60@nwk-avmta-2.sfbay.sun.com>; Wed, 16 Apr 2008 09:34:21 -0700 (PDT) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3GGYHiD880087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Apr 2008 09:34:18 -0700 (PDT) Date: Wed, 16 Apr 2008 09:34:17 -0700 From: Erik Nordmark Subject: Re: PSARC/2008/219 Committed API for packet interception In-reply-to: <4805CD83.6080100@Sun.COM> To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <48062A89.7070703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E8C7A0.1010609@Sun.COM> <47EA7E7B.7060003@sun.com> <47EADB92.8080700@Sun.COM> <47EBD118.4040300@sun.com> <47ED6804.9020601@Sun.COM> <47FFCD50.5090102@sun.com> <4805CD83.6080100@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 570 Darren Reed wrote: >>> Of these, the first (protocol addition/removal) is implied by >>> the creation of a new IP instance. The other two require >>> separate notification. >> >> That assumes all protocols are up and running in the kernel before the >> first interested consumer. Do we know that is the case? > > What I think you're missing is that all instances of a > protocol are to be announced via the net_instance_* > mechanism, not just those that are created at run time > as zones with exclusive instances are added. Ah - I hadn't realized that. Erik