From gd78059@sac.sfbay.sun.com Tue Sep 8 09:10:32 2009 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 n88GAW94017724 for ; Tue, 8 Sep 2009 09:10:32 -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 n88GAW6D011233; Tue, 8 Sep 2009 09:10: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 <0KPN00101U9J1700@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 10:10:31 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN00EU0U9H04B0@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 10:10:29 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n88GATi6058863; Tue, 08 Sep 2009 09:10:29 -0700 (PDT) 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 n88GARDw017719; Tue, 08 Sep 2009 09:10:27 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n88GARbU017715; Tue, 08 Sep 2009 09:10:27 -0700 (PDT) Date: Tue, 08 Sep 2009 09:10:27 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] To: PSARC-ext@sun.com Message-id: <200909081610.n88GARbU017715@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6620 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Public linked lists 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 08 September, 2009 4. Technical Description Problem ------- Unlike virtually every other FOSS, we Solaris has not common faciility that is *public* for driver developers for managing linked lists. Yet managing linked lists is one of the most common tasks that device driver developers are faced with. Solaris has a facility, but it was never reviewed by ARC and remains some form of private. Solution -------- We propose that the definitions and declarations that make up sys/list.h are added to the public Committed DDI. Note that these linked lists are actually doubly linked to allow O(1) insertions and removals anywhere on the list, as well as to allow efficient traversal in either direction. We are requesting Patch binding, although at present four of the functions interfaces described here are not present on Solaris 10 and would need to be backported. (The Patch binding makes this possible if some enterprising individual should choose to this, although the project team has no specific intention to do this at this time.) The functions not present on S10 are identified in the Exported Interfaces table below. Details ------- contains the following types: typedef struct list_node list_node_t; This is an opaque structure node on a linked list. It can be placed as a member of a structure that will be linked together. (Its valid to take the size of this structure, but individual members remain private.) typedef struct list list_t; This is an opaque structure representing a linked list itself. It is valid to take the size of this structure, but individual members remain private. The following functions are used to access linked lists. Note that the linked lists themselves are not protected by any locks; it is the responsibility of the developer to provide locking to protect the linkage of lists created with these functions. void list_create(list_t *, size_t size, size_t offset); This function initializes a new list. The driver supplies the storage for the list handle, and the size of an individual element, and the offset of a list_node_t within the element to use for the links of the list. void list_destroy(list_t *); This function destroys the list handle, including freeing up any resources which may have been internally allocated for the list. The list *must* be empty when this function is called. void list_insert_after(list_t *, void *reference_item, void *new_item); void list_insert_before(list_t *, void *reference_item, void *new_item); These functions insert new_item into the linked list at a location after or before the reference item, which must already be on the list. void list_insert_head(list_t *, void *new_item); void list_insert_tail(list_t *, void *new_item); These functions insert the new_item on the list at either the head or tail of the list. (The head is the first item, the tail is the last item). void list_remove(list_t *, void *item); This function removes the item from the list. void *list_remove_head(list_t *); void *list_remove_tail(list_t *); These functions remove the head (first) or tail (last) item from the list. The item removed is returned to the caller. If the list is empty when these functions are called, then no change is made and NULL is returned to the caller. void *list_head(list_t *); void *list_tail(list_t *); These functions simply return the head (first) or tail (last) item on the list. NULL is returned if the list is empty. void *list_next(list_t * void *reference_item); void *list_prev(list_t * void *reference_item); These functions returne the next or previous item in the list, relative to the named reference item which must be linked on the list. int list_is_empty(list_t *); This functions returns zero if the list has items in it, or non-zero otherwise. void list_link_init(list_node_t *node); This function initializes the list_node_t. It is functionally equivalent to bzero(node, sizeof (*node)); int list_link_active(list_node_t *); This functions returns non-zero if the node is on an active list. void list_move_tail(list_t *dst, list_t *src); This function is used to append the items on the src list to the end of the dst list. It is mandatory that the two lists were initialized using identical size and offset parameters. Upon completion, the src list will be empty. void list_link_replace(list_node_t *, list_node_t *); This function swaps two items on a list. Note that the items need not be on the same list, but extreme care must be used to ensure that both lists are locked, and that the lists were initialized with identical size and offset parameters. Interface Tables ---------------- Exported Interfaces +-----------------------+---------------+-------------------------------+ | Interface | Stability | Comments | +-----------------------+---------------+-------------------------------+ | | Committed | Header file | | list_node_t | Committed | Opaque datatype | | list_t | Committed | | | sizeof (list_node_t) | Committed | Sizes are committed | | sizeof (list_t) | Committed | | | list_create() | Committed | List handling functions | | list_destroy() | Committed | | | list_insert_after() | Committed | | | list_insert_before() | Committed | | | list_insert_head() | Committed | | | list_insert_tail() | Committed | | | list_remove() | Committed | | | list_remove_head() | Committed | Not currently in S10 | | list_remove_tail() | Committed | Not currently in S10 | | list_move_tail() | Committed | | | list_head() | Committed | | | list_tail() | Committed | | | list_next() | Committed | | | list_prev() | Committed | | | list_is_empty() | Committed | | | list_link_init() | Committed | Not currently in S10 | | list_link_replace() | Committed | Not currently in S10 | | list_link_active() | Committed | | +-----------------------+---------------+-------------------------------+ Imported Interfaces None. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Tue Sep 8 09:23:47 2009 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 n88GNk1u017990 for ; Tue, 8 Sep 2009 09:23:47 -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 n88GNW38008821 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Sep 2009 00:23:45 +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 <0KPN00D2XUVKFY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 09:23:44 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN0027WUVIGZE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 09:23:43 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n88GNf56002605 for ; Tue, 08 Sep 2009 16:23:42 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPN00500UST9800@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 17:23:27 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPN00C4UUV23G90@fe-emea-10.sun.com>; Tue, 08 Sep 2009 17:23:26 +0100 (BST) Date: Tue, 08 Sep 2009 17:23:25 +0100 From: Darren J Moffat Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <200909081610.n88GARbU017715@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com Message-id: <4AA684FD.5010301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 809 Garrett D'Amore - sun microsystems wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Public linked lists > 1.2. Name of Document Author/Supplier: > Author: Garrett D'Amore > 1.3 Date of This Document: > 08 September, 2009 > 4. Technical Description Makes perfect sense to me, I'd like the over similar data structures made public too, like the AVL trees, but I understand "not this case!". It would also be very useful it this was exposed in userland as well - particularly since already used in ZFS userland code and I've got a use case for it that I started coding for kcfd yesterday. So +1 as is but I'd like to see more in this area. -- Darren J Moffat From Gordon.Ross@sun.com Tue Sep 8 09:32:19 2009 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 n88GWJlV018204 for ; Tue, 8 Sep 2009 09:32:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88GWFLB001643 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 09:32:19 -0700 (PDT) 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 <0KPN00I17V9UAP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Sep 2009 09:32:18 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN008L9V9T6N60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Sep 2009 09:32:17 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n88GWH18024262 for ; Tue, 08 Sep 2009 16:32:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPN00100RD6Y800@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Sep 2009 10:32:17 -0600 (MDT) Received: from [129.148.169.152] ([unknown] [129.148.169.152]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPN001RSV9GDWB0@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 08 Sep 2009 10:32:04 -0600 (MDT) Date: Tue, 08 Sep 2009 12:32:04 -0400 From: Gordon Ross Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <200909081610.n88GARbU017715@sac.sfbay.sun.com> Sender: Gordon.Ross@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <1252427524.1085.4.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.26.3 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> Status: RO Content-Length: 390 Are the types and functions used on any other systems? Or something similar? Or would this be Solaris-specific? The one I've most often run across on other systems is the BSD-style (which Nevada has now). > Unlike virtually every other FOSS, we Solaris has not common faciility that > is *public* for driver developers for managing linked lists. > [...] > From gdamore@sun.com Tue Sep 8 09:38:46 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n88GcktX018275 for ; Tue, 8 Sep 2009 09:38:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88GckXo048082 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 10:38:46 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPN00E03VKLME00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 08 Sep 2009 09:38:45 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN00ELKVKKCF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 08 Sep 2009 09:38:44 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n88GciRn029087 for ; Tue, 08 Sep 2009 09:38:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPN00J00V1DGV00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 08 Sep 2009 09:38:44 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPN006S5VKAF010@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 08 Sep 2009 09:38:35 -0700 (PDT) Date: Tue, 08 Sep 2009 09:38:34 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <1252427524.1085.4.camel@dell6300gwr> Sender: Garrett.Damore@sun.com To: Gordon Ross Cc: PSARC-ext@sun.com Message-id: <4AA6888A.1000704@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1100 Gordon Ross wrote: > Are the types and functions used on any other systems? > Or something similar? Or would this be Solaris-specific? > > The one I've most often run across on other systems is the > BSD-style (which Nevada has now). > Wow. I didn't even know that queue.h was present. However, it is also not covered by any ARC case. I really, really wish CRTs and project teams would pay closer attention and not *deliver* header files into SUNWhea which are intended for internal (Consolidation Private or Project Private) use only. Anyway, these list functions would be Solaris-specific. The BSD queue functions, while richer, actually are defined as macros, so there isn't really a binary compatibility concern when using them. (There could be source compatibility concerns, however.) The list.h stuff is all defined as functions, which live in genunix. -- Garrett > > >> Unlike virtually every other FOSS, we Solaris has not common faciility that >> is *public* for driver developers for managing linked lists. >> [...] >> >> > > From carlsonj@workingcode.com Tue Sep 8 09:56:51 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n88Guo3B019369 for ; Tue, 8 Sep 2009 09:56:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88GukmW056264; Tue, 8 Sep 2009 10:56:49 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPN0050VWENT500@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 10:56:47 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN00DWOWEMZPD0@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 10:56:47 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n88GbPKt029396; Tue, 08 Sep 2009 16:56:46 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-1208626; Tue, 08 Sep 2009 16:56:45 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-93253; Tue, 08 Sep 2009 16:56:45 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-37890888; Tue, 08 Sep 2009 16:56:45 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n88Guigh029752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 08 Sep 2009 12:56:44 -0400 (EDT) Date: Tue, 08 Sep 2009 12:56:43 -0400 From: James Carlson Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA6888A.1000704@sun.com> To: "Garrett D'Amore" Cc: Gordon Ross , PSARC-ext@sun.com Message-id: <4AA68CCB.90601@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-EATSERVER-Metrics: carlson 1166; Body=3 Fuz1=3 Fuz2=3 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1513 Garrett D'Amore wrote: > Gordon Ross wrote: >> Are the types and functions used on any other systems? >> Or something similar? Or would this be Solaris-specific? >> >> The one I've most often run across on other systems is the >> BSD-style (which Nevada has now). >> > > Wow. I didn't even know that queue.h was present. However, it is also > not covered by any ARC case. I thought it was fwflash ... but my memory is fading. I know it was talked about before. > I really, really wish CRTs and project teams would pay closer attention > and not *deliver* header files into SUNWhea which are intended for > internal (Consolidation Private or Project Private) use only. > > Anyway, these list functions would be Solaris-specific. > > The BSD queue functions, while richer, actually are defined as macros, > so there isn't really a binary compatibility concern when using them. That part's not true. Macros actually have substantially worse binary compatibility issues to deal with: the macro itself and all data structures that it references simply can never change at all in any way. Remember the fileno() fiasco? At least with functions, we have symbolic tricks we can pull to get different (and compatible) behaviors depending on who calls the function and how it's called. Fortunately for the BSD queue macros, that really isn't an issue. They haven't changed in approximately forever. -- James Carlson 42.703N 71.076W From gdamore@sun.com Tue Sep 8 10:04:52 2009 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 n88H4plf020211 for ; Tue, 8 Sep 2009 10:04:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88H4l5J017855 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 10:04:51 -0700 (PDT) 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 <0KPN00M1VWS26R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:04:50 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN00877WRV6B70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:04:48 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n88H4hpL002799 for ; Tue, 08 Sep 2009 10:04:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPN00100WFI0900@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:04:43 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPN00ARWWRR1300@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:04:39 -0700 (PDT) Date: Tue, 08 Sep 2009 10:04:39 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA68CCB.90601@workingcode.com> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Gordon Ross , PSARC-ext@sun.com Message-id: <4AA68EA7.3010604@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2723 James Carlson wrote: > Garrett D'Amore wrote: > >> Gordon Ross wrote: >> >>> Are the types and functions used on any other systems? >>> Or something similar? Or would this be Solaris-specific? >>> >>> The one I've most often run across on other systems is the >>> BSD-style (which Nevada has now). >>> >>> >> Wow. I didn't even know that queue.h was present. However, it is also >> not covered by any ARC case. >> > > I thought it was fwflash ... but my memory is fading. I know it was > talked about before. > > >> I really, really wish CRTs and project teams would pay closer attention >> and not *deliver* header files into SUNWhea which are intended for >> internal (Consolidation Private or Project Private) use only. >> >> Anyway, these list functions would be Solaris-specific. >> >> The BSD queue functions, while richer, actually are defined as macros, >> so there isn't really a binary compatibility concern when using them. >> > > That part's not true. Macros actually have substantially worse binary > compatibility issues to deal with: the macro itself and all data > structures that it references simply can never change at all in any way. > This is true when the macro is used to reference binary structures from one binary object in another. > Remember the fileno() fiasco? At least with functions, we have symbolic > tricks we can pull to get different (and compatible) behaviors depending > on who calls the function and how it's called. > > Fortunately for the BSD queue macros, that really isn't an issue. They > haven't changed in approximately forever. > More to the point, the "macros" for the BSD queues are self-contained. That is to say, assuming you only use the macros within a single module, and not to access queues built into another binary object, then you are pretty much guaranteed that the results will be safe. (I.e. if you only use them to create and manage driver-private linked lists, then you will be safe.) This is because all of the possibly volatile bits of the implementation are actually compiled into the consumer itself, rather than residing someplace else where change can result in breakage (e.g. genunix). That said, I prefer the Solaris versions if only because the *implementation is not shared. While it means that there is function call overhead, at least the code in genunix won't be duplicated, resulting in hotter caches, and smaller binaries. Plus it allows for possible change. In theory, someone could, for example, add a locked initialization variant to these, so that the functions could be used with a lock that protects the list linkage itself. - Garrett From Nicolas.Williams@sun.com Tue Sep 8 10:20:32 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n88HKWOp020523 for ; Tue, 8 Sep 2009 10:20:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88HKSp6001279; Tue, 8 Sep 2009 11:20:31 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPN0080NXI65300@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 11:20:30 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN006HDXI5BR10@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 11:20:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n88HH07s012206; Tue, 08 Sep 2009 12:17:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n88HH0Cw012205; Tue, 08 Sep 2009 12:17:00 -0500 (CDT) Date: Tue, 08 Sep 2009 12:17:00 -0500 From: Nicolas Williams Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA68EA7.3010604@sun.com> To: "Garrett D'Amore" Cc: James Carlson , Gordon Ross , PSARC-ext@sun.com Message-id: <20090908171659.GB1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1335 On Tue, Sep 08, 2009 at 10:04:39AM -0700, Garrett D'Amore wrote: > >Remember the fileno() fiasco? At least with functions, we have symbolic > >tricks we can pull to get different (and compatible) behaviors depending > >on who calls the function and how it's called. > > > >Fortunately for the BSD queue macros, that really isn't an issue. They > >haven't changed in approximately forever. > > More to the point, the "macros" for the BSD queues are self-contained. > That is to say, assuming you only use the macros within a single module, ^^^^^^^^ But why should anyone assume that? (Yes, fileno() was intended to be used with FILE *, which was a very public interface. But nothing stops one from making the same sort of mistake with these macros.) I think the BSD queue macros should be public interfaces, if only because they are useful for porting software. Perhaps they should come with a loud warning that one must not make struct types/typedefs defined by the *_HEAD() and *_ENTRY() macros, part of any public interface, though since they have never changed and we have no reason to think that they ever will... Incidentally, Linux has its own list API, including inlined functions. It'd be nice to have compatibility with that. Also, I second Darren's sentiment w.r.t. the AVL tree API. Nico -- From gdamore@sun.com Tue Sep 8 10:35:09 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n88HZ9ts021041 for ; Tue, 8 Sep 2009 10:35:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88HZ7F1008142 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 11:35:08 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPN0091JY6KN700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 11:35:08 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN0062VY6JBR20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 11:35:07 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n88HZ6O5007023 for ; Tue, 08 Sep 2009 10:35:06 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPN00400XZDOQ00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:35:06 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPN00AFPY6H13D0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:35:06 -0700 (PDT) Date: Tue, 08 Sep 2009 10:35:05 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <20090908171659.GB1033@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: James Carlson , Gordon Ross , PSARC-ext@sun.com Message-id: <4AA695C9.8040409@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2430 Nicolas Williams wrote: > On Tue, Sep 08, 2009 at 10:04:39AM -0700, Garrett D'Amore wrote: > >>> Remember the fileno() fiasco? At least with functions, we have symbolic >>> tricks we can pull to get different (and compatible) behaviors depending >>> on who calls the function and how it's called. >>> >>> Fortunately for the BSD queue macros, that really isn't an issue. They >>> haven't changed in approximately forever. >>> >> More to the point, the "macros" for the BSD queues are self-contained. >> That is to say, assuming you only use the macros within a single module, >> > ^^^^^^^^ > > But why should anyone assume that? (Yes, fileno() was intended to be > used with FILE *, which was a very public interface. But nothing stops > one from making the same sort of mistake with these macros.) > > I think the BSD queue macros should be public interfaces, if only > because they are useful for porting software. Perhaps they should come > with a loud warning that one must not make struct types/typedefs defined > by the *_HEAD() and *_ENTRY() macros, part of any public interface, > though since they have never changed and we have no reason to think that > they ever will... > > Incidentally, Linux has its own list API, including inlined functions. > It'd be nice to have compatibility with that. Also, I second Darren's > sentiment w.r.t. the AVL tree API. > Okay, but all of *those* comments are *not this case*. Unless someone believes this case ought to be abandoned in favor of the queue.h macros. For my nickel, I think its sad that we have to have two "competing" list types in the kernel. Converting queue.h into list.h (or vice versa) is such a trivial task that it should never take an engineer more than a little bit of time. Compared to the major effort to port a device driver from one OS to another (and you might say I know just a little bit about what's involved there!), dealing with the list handling stuff is just minor noise. Given that, I'd actually prefer to remove the queue.h interfaces, and promote list.h. list.h interfaces are safer than BSD queue.h (see above argument), and have been around and available since ~forever. Driver developers that *really* want to use queue.h are of course free to import private copies of that header file into their own source code, although I wish we saw less of that inside ON. - Garrett From carlsonj@workingcode.com Tue Sep 8 10:47:54 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n88HlsuY022037 for ; Tue, 8 Sep 2009 10:47:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88Hlnr0014738; Tue, 8 Sep 2009 11:47:52 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPN00A01YRSUY00@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 11:47:52 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN00644YRRBS30@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 11:47:51 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n88Hjd08028953; Tue, 08 Sep 2009 17:47:51 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-521001; Tue, 08 Sep 2009 17:47:51 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-150935; Tue, 08 Sep 2009 17:47:51 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-11645947; Tue, 08 Sep 2009 17:47:50 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n88Hln58005603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 08 Sep 2009 13:47:50 -0400 (EDT) Date: Tue, 08 Sep 2009 13:47:48 -0400 From: James Carlson Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA695C9.8040409@sun.com> To: "Garrett D'Amore" Cc: Gordon Ross , PSARC-ext@sun.com Message-id: <4AA698C4.5010808@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-EATSERVER-Metrics: carlson 1166; Body=3 Fuz1=3 Fuz2=3 X-Antispam: No, score=-0.2/5.0, scanned in 0.190sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1090 Garrett D'Amore wrote: > Nicolas Williams wrote: >> Incidentally, Linux has its own list API, including inlined functions. >> It'd be nice to have compatibility with that. Also, I second Darren's >> sentiment w.r.t. the AVL tree API. >> > > Okay, but all of *those* comments are *not this case*. Unless someone > believes this case ought to be abandoned in favor of the queue.h macros. I don't. I think both should exist. > For my nickel, I think its sad that we have to have two "competing" list > types in the kernel. Agreed. > Given that, I'd actually prefer to remove the queue.h interfaces, and > promote list.h. list.h interfaces are safer than BSD queue.h (see above > argument), and have been around and available since ~forever. Please don't! The BSD queue.h interfaces are used in both kernel *and* user-space code -- they're also present on Linux -- and the lack of them on classic Solaris is a very annoying application portability issue. Removing them would be a big step backwards. -- James Carlson 42.703N 71.076W From Gordon.Ross@sun.com Tue Sep 8 10:50:50 2009 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 n88HoouO022213 for ; Tue, 8 Sep 2009 10:50:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88HonXd009519 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 10:50:50 -0700 (PDT) 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 <0KPN0040JYWOWK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:50:48 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN0088UYWN6NC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:50:48 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n88HolME001209 for ; Tue, 08 Sep 2009 17:50:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPN00H00XYZWN00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 11:50:47 -0600 (MDT) Received: from [129.148.169.152] ([unknown] [129.148.169.152]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPN00L9XYWB5L20@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 11:50:35 -0600 (MDT) Date: Tue, 08 Sep 2009 13:50:35 -0400 From: Gordon Ross Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA695C9.8040409@sun.com> Sender: Gordon.Ross@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <1252432235.1085.16.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.26.3 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> Status: RO Content-Length: 1543 > Okay, but all of *those* comments are *not this case*. Unless someone > believes this case ought to be abandoned in favor of the queue.h macros. I did not intend to suggest that. Having both is OK. Just document which is preferred when and why. (Solaris value add vs portability) > For my nickel, I think its sad that we have to have two "competing" list > types in the kernel. Converting queue.h into list.h (or vice versa) is > such a trivial task that it should never take an engineer more than a > little bit of time. Compared to the major effort to port a device > driver from one OS to another (and you might say I know just a little > bit about what's involved there!), dealing with the list handling stuff > is just minor noise. While it may seem trivial to you, it may not always be desirable. The code I spend most of my time in uses and I've kept it to reduce differences from other ports of the code. > Given that, I'd actually prefer to remove the queue.h interfaces, and > promote list.h. list.h interfaces are safer than BSD queue.h (see above > argument), and have been around and available since ~forever. You're not making that part of this case, right? > Driver developers that *really* want to use queue.h are of course free > to import private copies of that header file into their own source code, > although I wish we saw less of that inside ON. I assume someone integrated because they were tired of dealing with N private copies of it scattered around. Gordon From gdamore@sun.com Tue Sep 8 10:54:20 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n88HsJ9c022607 for ; Tue, 8 Sep 2009 10:54:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88HsFOM017836 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 11:54:19 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPN00J01Z2H3J00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:54:17 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN00EFTZ2HCD60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:54:17 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n88HsHFX015613 for ; Tue, 08 Sep 2009 10:54:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPN00I00YTE7J00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:54:17 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPN00KGBZ2GIMF0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:54:17 -0700 (PDT) Date: Tue, 08 Sep 2009 10:54:16 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <1252432235.1085.16.camel@dell6300gwr> Sender: Garrett.Damore@sun.com To: Gordon Ross Cc: PSARC-ext@sun.com Message-id: <4AA69A48.3000002@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <1252432235.1085.16.camel@dell6300gwr> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2051 Gordon Ross wrote: >> Okay, but all of *those* comments are *not this case*. Unless someone >> believes this case ought to be abandoned in favor of the queue.h macros. >> > > I did not intend to suggest that. Having both is OK. > Just document which is preferred when and why. > (Solaris value add vs portability) > > >> For my nickel, I think its sad that we have to have two "competing" list >> types in the kernel. Converting queue.h into list.h (or vice versa) is >> such a trivial task that it should never take an engineer more than a >> little bit of time. Compared to the major effort to port a device >> driver from one OS to another (and you might say I know just a little >> bit about what's involved there!), dealing with the list handling stuff >> is just minor noise. >> > > While it may seem trivial to you, it may not always be desirable. > The code I spend most of my time in uses and I've > kept it to reduce differences from other ports of the code. > Ok. Although, as I said, I've found that this is one of the areas of code where the differences matter the *least*, at least in the various device drivers I worked with. > >> Given that, I'd actually prefer to remove the queue.h interfaces, and >> promote list.h. list.h interfaces are safer than BSD queue.h (see above >> argument), and have been around and available since ~forever. >> > > You're not making that part of this case, right? > No. Jim Carlson has raised the point that this header is used in *userland* code. Ugh. > >> Driver developers that *really* want to use queue.h are of course free >> to import private copies of that header file into their own source code, >> although I wish we saw less of that inside ON. >> > > I assume someone integrated because they were > tired of dealing with N private copies of it scattered around. > Possibly. However, in that case it *ought* to have been properly ARC'd, and an interface stability granted to it. - Garrett From gdamore@sun.com Tue Sep 8 10:56:07 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n88Hu6kU022699 for ; Tue, 8 Sep 2009 10:56:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n88Hu3vq018456 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 11:56:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPN00J0FZ5F8Y00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:56:03 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN00EYZZ5ACB50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:56:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n88HtwVj015829 for ; Tue, 08 Sep 2009 10:55:58 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPN00800YWG5L00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:55:58 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPN001GKZ59ZF40@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 10:55:58 -0700 (PDT) Date: Tue, 08 Sep 2009 10:55:57 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA698C4.5010808@workingcode.com> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Gordon Ross , PSARC-ext@sun.com Message-id: <4AA69AAD.1070006@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 807 James Carlson wrote: > >> Given that, I'd actually prefer to remove the queue.h interfaces, and >> promote list.h. list.h interfaces are safer than BSD queue.h (see above >> argument), and have been around and available since ~forever. >> > > Please don't! > > The BSD queue.h interfaces are used in both kernel *and* user-space code > -- they're also present on Linux -- and the lack of them on classic > Solaris is a very annoying application portability issue. > > Removing them would be a big step backwards. > > Ok. Well in this case, someone else should raise the commitment level and ARC them. Just having them "appear" on Solaris without any ARC coverage or interface stability is IMO less than helpful. It looks like this arrived with the Packet Filter Hooks stuff. - Garrett From casper@holland.sun.com Tue Sep 8 11:02:50 2009 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 n88I2ohm022976 for ; Tue, 8 Sep 2009 11:02:50 -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 n88I2gbn005413; Tue, 8 Sep 2009 11:02:49 -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 <0KPN00C3HZGO9800@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 12:02:48 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPN006D2ZGKBS40@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 12:02:45 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n88I2fT9022748; Tue, 08 Sep 2009 19:02:41 +0100 (BST) Date: Tue, 08 Sep 2009 20:02:41 +0200 From: Casper.Dik@sun.com Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <20090908171659.GB1033@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: "Garrett D'Amore" , James Carlson , Gordon Ross , PSARC-ext@sun.com Message-id: <200909081802.n88I2fT9022748@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> Status: RO Content-Length: 459 >Incidentally, Linux has its own list API, including inlined functions. >It'd be nice to have compatibility with that. Also, I second Darren's >sentiment w.r.t. the AVL tree API. Inlining is not much different from macro's. I've used the AVL lists for the "Turbo charged SVR4 packages" and they work really well and they're about as quick appending to a linked list. (SQL was clearly not properly suited for handling a very simple database) Casper From Nicolas.Williams@sun.com Tue Sep 8 12:34:42 2009 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 n88JYfRN004769 for ; Tue, 8 Sep 2009 12:34:41 -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 n88JYXZ0008051; Tue, 8 Sep 2009 20:34:38 +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 <0KPO00L073POOM00@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 13:34:36 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPO006UU3PNC3A0@brm-avmta-1.central.sun.com>; Tue, 08 Sep 2009 13:34:35 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n88JV7gZ012268; Tue, 08 Sep 2009 14:31:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n88JV7VJ012267; Tue, 08 Sep 2009 14:31:07 -0500 (CDT) Date: Tue, 08 Sep 2009 14:31:06 -0500 From: Nicolas Williams Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <200909081802.n88I2fT9022748@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: "Garrett D'Amore" , James Carlson , Gordon Ross , PSARC-ext@sun.com Message-id: <20090908193106.GD1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <200909081802.n88I2fT9022748@dm-holland-02.uk.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 778 On Tue, Sep 08, 2009 at 08:02:41PM +0200, Casper.Dik@Sun.COM wrote: > >Incidentally, Linux has its own list API, including inlined functions. > >It'd be nice to have compatibility with that. Also, I second Darren's > >sentiment w.r.t. the AVL tree API. > > Inlining is not much different from macro's. I've used the AVL lists for Indeed. I mentioned it for that reason. But then, the Linux kernel doesn't pretend to have ABI compatibility for anything other than the interfaces to user-land (like glibc). > the "Turbo charged SVR4 packages" and they work really well and they're > about as quick appending to a linked list. (SQL was clearly not properly > suited for handling a very simple database) The AVL API should be made a public API. Yes, yes, not this case. From Darren.Reed@sun.com Tue Sep 8 16:58:47 2009 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 n88NwkdI023205 for ; Tue, 8 Sep 2009 16:58:46 -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 n88NwLKa001656 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Sep 2009 07:58:45 +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 <0KPO0030BFXVE500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 17:58:43 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPO00JEZFXU9T30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 17:58:42 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n88NwfpZ006147 for ; Tue, 08 Sep 2009 23:58:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPO00500FVMQ100@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 00:58:41 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPO001HQFXO3LC0@fe-emea-09.sun.com>; Wed, 09 Sep 2009 00:58:38 +0100 (BST) Date: Tue, 08 Sep 2009 16:59:28 -0700 From: Darren Reed Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <200909081610.n88GARbU017715@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com Message-id: <4AA6EFE0.40102@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090608) Status: RO Content-Length: 785 On 8/09/09 09:10 AM, Garrett D'Amore - sun microsystems wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Public linked lists > 1.2. Name of Document Author/Supplier: > Author: Garrett D'Amore > 1.3 Date of This Document: > 08 September, 2009 > 4. Technical Description > > Problem > ------- > > Unlike virtually every other FOSS, we Solaris has not common faciility that > is *public* for driver developers for managing linked lists. > This is incorrect... Solaris has been shipping for a while now and whilst it may not be a Public interface so far as Solaris goes, it is a public/committed interface for BSD. Darren From James.McPherson@Sun.COM Tue Sep 8 17:02:37 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8902b5e023363 for ; Tue, 8 Sep 2009 17:02:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8902YaN011129 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 18:02:34 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPO0030HG48UD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 18:02:32 -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 <0KPO00JS7G43A630@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 18:02:31 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8902RvA018979 for ; Wed, 09 Sep 2009 00:02:27 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPO00B00FYPEX00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 08:02:27 +0800 (SGT) Received: from blinder ([unknown] [220.157.71.44]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPO00IPPG40AV00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 08:02:26 +0800 (SGT) Date: Wed, 09 Sep 2009 10:02:22 +1000 From: "James C. McPherson" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA69AAD.1070006@sun.com> Sender: James.McPherson@Sun.COM To: "Garrett D'Amore" Cc: James Carlson , Gordon Ross , PSARC-ext@Sun.COM Message-id: <20090909100222.00001e54@blinder> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.4; i386-pc-solaris2.11) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> Status: RO Content-Length: 1189 On Tue, 08 Sep 2009 10:55:57 -0700 Garrett D'Amore wrote: > James Carlson wrote: > > > >> Given that, I'd actually prefer to remove the queue.h interfaces, and > >> promote list.h. list.h interfaces are safer than BSD queue.h (see above > >> argument), and have been around and available since ~forever. > >> > > > > Please don't! > > > > The BSD queue.h interfaces are used in both kernel *and* user-space code > > -- they're also present on Linux -- and the lack of them on classic > > Solaris is a very annoying application portability issue. > > > > Removing them would be a big step backwards. > > > > > > Ok. Well in this case, someone else should raise the commitment level > and ARC them. Just having them "appear" on Solaris without any ARC > coverage or interface stability is IMO less than helpful. > > It looks like this arrived with the Packet Filter Hooks stuff. Correct: 6418698 PSARC/2005/334 - Packet Filtering Hooks API (not introduced by fwflash at all, I just used what was already there) James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog From gdamore@sun.com Tue Sep 8 17:07:19 2009 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 n8907IGp027465 for ; Tue, 8 Sep 2009 17:07:19 -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 n8907En5029189 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Sep 2009 01:07:18 +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 <0KPO00L0RGC3GY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 08 Sep 2009 17:07:15 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPO0026JGC1OUF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 08 Sep 2009 17:07:13 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8907D39027725 for ; Tue, 08 Sep 2009 17:07:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPO00600G8WPP00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 08 Sep 2009 17:07:13 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPO00CBHGC165E0@fe-sfbay-09.sun.com>; Tue, 08 Sep 2009 17:07:13 -0700 (PDT) Date: Tue, 08 Sep 2009 17:07:13 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA6EFE0.40102@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4AA6F1B1.306@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <4AA6EFE0.40102@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 882 Darren Reed wrote: > On 8/09/09 09:10 AM, Garrett D'Amore - sun microsystems wrote: >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Public linked lists >> 1.2. Name of Document Author/Supplier: >> Author: Garrett D'Amore >> 1.3 Date of This Document: >> 08 September, 2009 >> 4. Technical Description >> >> Problem >> ------- >> >> Unlike virtually every other FOSS, we Solaris has not common >> faciility that >> is *public* for driver developers for managing linked lists. >> > > This is incorrect... > > Solaris has been shipping for a while now and > whilst it may not be a Public interface so far as Solaris goes, > it is a public/committed interface for BSD. Its not public for Solaris. - Garrett From Darren.Reed@Sun.COM Tue Sep 8 17:30:47 2009 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 n890Ulwk027771 for ; Tue, 8 Sep 2009 17:30:47 -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 n890UaaM018310 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Sep 2009 08:30:46 +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 <0KPO00C0DHF80U00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 17:30:44 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPO00HXSHF6I290@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 17:30:43 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n890UgKC007612 for ; Wed, 09 Sep 2009 00:30:42 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPO00H00GURLW00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 01:30:24 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPO00CXTHEI3GB0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 01:30:21 +0100 (BST) Date: Tue, 08 Sep 2009 17:31:10 -0700 From: Darren Reed Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA69AAD.1070006@sun.com> Sender: Darren.Reed@Sun.COM To: "Garrett D'Amore" Cc: James Carlson , Gordon Ross , PSARC-ext@Sun.COM Message-id: <4AA6F74E.2030607@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090608) Status: RO Content-Length: 3657 On 8/09/09 10:55 AM, Garrett D'Amore wrote: > James Carlson wrote: >> >>> Given that, I'd actually prefer to remove the queue.h interfaces, and >>> promote list.h. list.h interfaces are safer than BSD queue.h (see >>> above >>> argument), and have been around and available since ~forever. >>> >> >> Please don't! >> >> The BSD queue.h interfaces are used in both kernel *and* user-space code >> -- they're also present on Linux -- and the lack of them on classic >> Solaris is a very annoying application portability issue. >> >> Removing them would be a big step backwards. >> >> > > Ok. Well in this case, someone else should raise the commitment level > and ARC them. Just having them "appear" on Solaris without any ARC > coverage or interface stability is IMO less than helpful. > > It looks like this arrived with the Packet Filter Hooks stuff. Because that was the easiest way to get it in. At the time there was both programming desire and portability concerns and I was not interested in the "lengthy discussion" that would likely ensure on the PSARC mailing list if I tried to them introduced as a stable interface. With the "new and improved" PSARC, maybe it would be an easier task to raise their commitment level now. But now that the topic has been brought up, maybe sometime soon would be appropriate... btw, the interfaces are only "safer" in some respects: for example, they're less safe with types. The interfaces all require explicit types be used for every structure. You cannot easily insert something of "type a" into a list of "type b". With the gratuitous use of "void *" in , simple protection such as this is non existent. Personally, I prefer the interfaces for another reason: when you're choosing a "type of list" to store data in, you need to make a conscious choice about whether it is a linked listed, tailq, circular queue, etc. IMHO, this plays an important role in how you manage the data and especially for how others view the code later. Whilst is more flexible like that, I think it opens up more risk by allowing one programmer to use it as a list and someone else to expect it to be a circular queue because the way data is organised may differ significantly. But this is just an opinion. Both interfaces suffer from other issues, such as if a data structure is common to more than one module and the location of the list data elements change in the structure, only updating one module is likely to cause problems. But this is a generic C problem. Whilst with , any change to list_t or list_node_t requires that all of code using that interface needs to be updated, with the model, only "matching binaries" need to be updated. I'm not really worried about this, for two reasons: - the core data structures are very stable, it has been more common for newer list types to be added than the structures updated; - if/when they do change, it is likely to be a significant flag day. (both reasons apply to both sets of interfaces.) I suspect that any change to the internal structures would draw a lot of attention, even if it were "to provide locked(safe) API" as the seemingly better alternative would be to just build a complete new set of macros/functions that used their own data structures, rather than impose a new operational paradigm on code that doesn't have any need for it. So the only significant difference that I'm aware of is that the interfaces offer type safety whereas the one in does not. For some people this might be important, for others not. Darren From gdamore@sun.com Tue Sep 8 18:52:45 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n891qiKi029227 for ; Tue, 8 Sep 2009 18:52:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n891qiJR054384 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Sep 2009 19:52:44 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPO00G05L7WAQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 19:52:44 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPO00JC0L7RA690@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 19:52:44 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n891qd8c003539 for ; Tue, 08 Sep 2009 18:52:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPO00F00L59YP00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 18:52:39 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPO00FIML7QK070@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Sep 2009 18:52:39 -0700 (PDT) Date: Tue, 08 Sep 2009 18:52:37 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA6F74E.2030607@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: James Carlson , Gordon Ross , PSARC-ext@sun.com Message-id: <4AA70A65.60903@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4515 My brief comments: 1) We need a list API. 2) I'm of the opinion that having multiple APIs in the DDI to accomplish the same thing is not constructive. 3) should never have been delivered in SUNWhea without a supporting ARC case. (But then neither should have sys/list.h.) 4) I'm not interested in comparing sys/list.h vs. sys/queue.h. I have my opinions, and a big discussion will just degenerate into bikeshedding. 5) If a Member feels that sys/queue.h is preferable to sys/list.h, then I think that Member should derail this case (at which point I'll probably just withdraw it) and then we can try to identify a list interface that is best suited for the DDI. -- Garrett Darren Reed wrote: > On 8/09/09 10:55 AM, Garrett D'Amore wrote: >> James Carlson wrote: >>> >>>> Given that, I'd actually prefer to remove the queue.h interfaces, and >>>> promote list.h. list.h interfaces are safer than BSD queue.h (see >>>> above >>>> argument), and have been around and available since ~forever. >>>> >>> >>> Please don't! >>> >>> The BSD queue.h interfaces are used in both kernel *and* user-space >>> code >>> -- they're also present on Linux -- and the lack of them on classic >>> Solaris is a very annoying application portability issue. >>> >>> Removing them would be a big step backwards. >>> >>> >> >> Ok. Well in this case, someone else should raise the commitment >> level and ARC them. Just having them "appear" on Solaris without any >> ARC coverage or interface stability is IMO less than helpful. >> >> It looks like this arrived with the Packet Filter Hooks stuff. > > Because that was the easiest way to get it in. At the time there was > both programming desire and portability concerns and I was not > interested in the "lengthy discussion" that would likely ensure on the > PSARC mailing list if I tried to them introduced as a stable interface. > > With the "new and improved" PSARC, maybe it would be an easier > task to raise their commitment level now. > > But now that the topic has been brought up, maybe sometime soon > would be appropriate... > > btw, the interfaces are only "safer" in some respects: > for example, they're less safe with types. The interfaces > all require explicit types be used for every structure. You cannot > easily insert something of "type a" into a list of "type b". With > the gratuitous use of "void *" in , simple protection such > as this is non existent. > > Personally, I prefer the interfaces for another reason: > when you're choosing a "type of list" to store data in, you need to > make a conscious choice about whether it is a linked listed, tailq, > circular queue, etc. IMHO, this plays an important role in how > you manage the data and especially for how others view the code > later. Whilst is more flexible like that, I think it > opens up more risk by allowing one programmer to use it as > a list and someone else to expect it to be a circular queue > because the way data is organised may differ significantly. > But this is just an opinion. > > Both interfaces suffer from other issues, such as if a data structure > is common to more than one module and the location of the list > data elements change in the structure, only updating one module > is likely to cause problems. But this is a generic C problem. > > Whilst with , any change to list_t or list_node_t requires > that all of code using that interface needs to be updated, with the > model, only "matching binaries" need to be updated. > I'm not really worried about this, for two reasons: > - the core data structures are very stable, it has been more common > for newer list types to be added than the structures updated; > - if/when they do change, it is likely to be a significant flag day. > (both reasons apply to both sets of interfaces.) > > I suspect that any change to the internal structures would draw a lot > of attention, even if it were "to provide locked(safe) API" as the > seemingly better alternative would be to just build a complete new > set of macros/functions that used their own data structures, rather > than impose a new operational paradigm on code that doesn't have > any need for it. > > So the only significant difference that I'm aware of is that the > interfaces offer type safety whereas the one in > does not. For some people this might be important, > for others not. > > Darren > From carlsonj@workingcode.com Wed Sep 9 08:35:02 2009 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 n89FZ0sd002096 for ; Wed, 9 Sep 2009 08:35:01 -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 n89FYgK7014906; Wed, 9 Sep 2009 16:34:56 +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 <0KPP00G3XNA7S900@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Sep 2009 08:34:55 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPP0057WNA6VYF0@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Sep 2009 08:34:55 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n89EkJ9p016922; Wed, 09 Sep 2009 15:34:54 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-1288591; Wed, 09 Sep 2009 15:17:55 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-2126016; Wed, 09 Sep 2009 15:17:54 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-114230; Wed, 09 Sep 2009 15:17:54 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n89FHr9t012586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 09 Sep 2009 11:17:53 -0400 (EDT) Date: Wed, 09 Sep 2009 11:17:52 -0400 From: James Carlson Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA70A65.60903@sun.com> To: "Garrett D'Amore" Cc: Darren Reed , Gordon Ross , PSARC-ext@sun.com Message-id: <4AA7C720.9060308@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson 1181; Body=4 Fuz1=4 Fuz2=4 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> <4AA70A65.60903@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2526 Garrett D'Amore wrote: > My brief comments: > > 1) We need a list API. Agreed. > 2) I'm of the opinion that having multiple APIs in the DDI to accomplish > the same thing is not constructive. It's certainly suboptimal. But where there are two or more important and conflicting traditions, what do you do? > 3) should never have been delivered in SUNWhea without a > supporting ARC case. (But then neither should have sys/list.h.) I disagree with that assertion. The contents of SUNWhea is not itself a documented interface -- in other words, what determines stability level is system documentation (man pages), and not what package delivers something or where it appears in the file system. We have historically shipped a mix of public and private interfaces via SUNWhea. Long ago, I filed a CR (forget the number) that suggested breaking up SUNWhea (and the SUNWarc* and perhaps other) package into public and private bits, so that we could install only public interfaces by default, and exclude private ones from accidental discovery. (Obviously, users who need to can always install the private packages; we'd still ship them -- perhaps with even more things included -- but just not install by default.) Think of it as linker mapfiles for packaging. The idea, unfortunately, went nowhere. Too many people were either skeptical of the utility of breaking up SUNWhea or of the value of trying to segregate private interfaces better. In this case, sys/list.h was Consolidation Private and sys/queue.h was (apparently) intended as Project Private but somehow used as though it were Consolidation Private. In any event, those sorts of interfaces do not *necessarily* need ARC review. Though I agree that some ARC review would have been better than not having it at all. > 5) If a Member feels that sys/queue.h is preferable to sys/list.h, then > I think that Member should derail this case (at which point I'll > probably just withdraw it) and then we can try to identify a list > interface that is best suited for the DDI. No longer a member, but I think that completely misses the point. The point is: - go ahead and add stable support for ; we need it. - leave where it is; the world needs it. - someone (not necessarily you) should provide a case that documents , because it clearly slipped through the process cracks. - these things are unrelated. Really. -- James Carlson 42.703N 71.076W From gdamore@sun.com Wed Sep 9 08:55:32 2009 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 n89FtWM2002649 for ; Wed, 9 Sep 2009 08:55:32 -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 n89FtTpm002066 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Sep 2009 16:55:31 +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 <0KPP00BY4O8HH110@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 09:55:29 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPP002ELO513N80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 09:53:25 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n89FrO8f007630 for ; Wed, 09 Sep 2009 08:53:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPP00L00NEWY500@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 08:53:24 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPP002LRO4Y3N70@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 08:53:23 -0700 (PDT) Date: Wed, 09 Sep 2009 08:53:22 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA7C720.9060308@workingcode.com> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Darren Reed , Gordon Ross , PSARC-ext@sun.com Message-id: <4AA7CF72.4010702@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> <4AA70A65.60903@sun.com> <4AA7C720.9060308@workingcode.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2045 James Carlson wrote: >> 3) should never have been delivered in SUNWhea without a >> supporting ARC case. (But then neither should have sys/list.h.) >> > > I disagree with that assertion. The contents of SUNWhea is not itself a > documented interface -- in other words, what determines stability level > is system documentation (man pages), and not what package delivers > something or where it appears in the file system. > > We have historically shipped a mix of public and private interfaces via > SUNWhea. Long ago, I filed a CR (forget the number) that suggested > breaking up SUNWhea (and the SUNWarc* and perhaps other) package into > public and private bits, so that we could install only public interfaces > by default, and exclude private ones from accidental discovery. > (Obviously, users who need to can always install the private packages; > we'd still ship them -- perhaps with even more things included -- but > just not install by default.) > > Think of it as linker mapfiles for packaging. The idea, unfortunately, > went nowhere. Too many people were either skeptical of the utility of > breaking up SUNWhea or of the value of trying to segregate private > interfaces better. > > I'm not of the opinion that breaking up SUNWhea into smaller packages is useful. I *am* of the opinion that headers which are Project Private, or possibly Consolidation Private, should not be packaged at all. (I'd probably grant a special exception for Consolidation Private interfaces which are *intended* for public consumption at some future date, but even that could probably just as easily be dealt with by a future push after ARC approves the interfaces for public consumption.) I suppose at one point having those headers on the system was useful for debugging back when people had to manually work out structures in adb. These days with CTF they are completely unnecessary. Whenever I easily I can, I remove project private (especially *driver private!*) headers from packaging. -- Garrett From casper@holland.sun.com Wed Sep 9 09:01:19 2009 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 n89G1Jrw003104 for ; Wed, 9 Sep 2009 09:01:19 -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 n89G14Rf014118; Wed, 9 Sep 2009 09:01:18 -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 <0KPP00D19OI6BW00@brm-avmta-1.central.sun.com>; Wed, 09 Sep 2009 10:01:18 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPP0026DOI54P60@brm-avmta-1.central.sun.com>; Wed, 09 Sep 2009 10:01:17 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n89G1EcB043896; Wed, 09 Sep 2009 17:01:14 +0100 (BST) Date: Wed, 09 Sep 2009 18:01:14 +0200 From: Casper.Dik@sun.com Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA7CF72.4010702@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: James Carlson , Darren Reed , Gordon Ross , PSARC-ext@sun.com Message-id: <200909091601.n89G1EcB043896@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> <4AA70A65.60903@sun.com> <4AA7C720.9060308@workingcode.com> <4AA7CF72.4010702@sun.com> Status: RO Content-Length: 355 >I suppose at one point having those headers on the system was useful for >debugging back when people had to manually work out structures in adb. >These days with CTF they are completely unnecessary. Whenever I easily >I can, I remove project private (especially *driver private!*) headers >from packaging. There's still: pidentd, lsof. Casper From Nicolas.Williams@sun.com Wed Sep 9 09:05:10 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n89G5Afu003188 for ; Wed, 9 Sep 2009 09:05:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n89G52oR001075; Wed, 9 Sep 2009 10:05:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPP00I0HOOI2R00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Sep 2009 09:05:06 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPP00GE1OOFYO30@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Sep 2009 09:05:03 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n89G1XET013152; Wed, 09 Sep 2009 11:01:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n89G1XFk013151; Wed, 09 Sep 2009 11:01:33 -0500 (CDT) Date: Wed, 09 Sep 2009 11:01:33 -0500 From: Nicolas Williams Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA7CF72.4010702@sun.com> To: "Garrett D'Amore" Cc: James Carlson , Darren Reed , Gordon Ross , PSARC-ext@sun.com Message-id: <20090909160133.GP1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> <4AA70A65.60903@sun.com> <4AA7C720.9060308@workingcode.com> <4AA7CF72.4010702@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1431 On Wed, Sep 09, 2009 at 08:53:22AM -0700, Garrett D'Amore wrote: > I'm not of the opinion that breaking up SUNWhea into smaller packages is > useful. I *am* of the opinion that headers which are Project Private, > or possibly Consolidation Private, should not be packaged at all. (I'd > probably grant a special exception for Consolidation Private interfaces > which are *intended* for public consumption at some future date, but > even that could probably just as easily be dealt with by a future push > after ARC approves the interfaces for public consumption.) Before OpenSolaris those private headers were quite useful to customers by hinting at implementation details that help observe the system. Now customers have source. If they want to use private interfaces, they will. Shipping or not shipping such headers is not terribly important, but documenting the Public interfaces and putting a warning in the private headers is. > I suppose at one point having those headers on the system was useful for > debugging back when people had to manually work out structures in adb. Among other things. > These days with CTF they are completely unnecessary. Whenever I easily CTF doesn't capture C pre-processor #defines. CTF doesn't capture extern function prototypes. CTF is not a replacement for shipping header files -- CTF really has nothing to do with shipping or not shipping private headers. Nico -- From carlsonj@workingcode.com Wed Sep 9 09:12:14 2009 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 n89GCEvF007133 for ; Wed, 9 Sep 2009 09:12:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n89GC9Sb024177; Wed, 9 Sep 2009 09:12:11 -0700 (PDT) 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 <0KPP00N39P0B3D00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Sep 2009 09:12:11 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPP00JVLP0AAG30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Sep 2009 09:12:10 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n89G2YEJ029402; Wed, 09 Sep 2009 16:12:10 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-600342; Wed, 09 Sep 2009 16:12:10 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-1715614; Wed, 09 Sep 2009 16:12:08 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-17698543; Wed, 09 Sep 2009 16:12:08 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n89GC7Nd019731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 09 Sep 2009 12:12:07 -0400 (EDT) Date: Wed, 09 Sep 2009 12:12:07 -0400 From: James Carlson Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA7CF72.4010702@sun.com> To: "Garrett D'Amore" Cc: Darren Reed , Gordon Ross , PSARC-ext@sun.com Message-id: <4AA7D3D7.1060609@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson 1181; Body=4 Fuz1=4 Fuz2=4 X-Antispam: No, score=-0.7/5.0, scanned in 0.207sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> <4AA70A65.60903@sun.com> <4AA7C720.9060308@workingcode.com> <4AA7CF72.4010702@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2566 Garrett D'Amore wrote: > James Carlson wrote: >> Think of it as linker mapfiles for packaging. The idea, unfortunately, >> went nowhere. Too many people were either skeptical of the utility of >> breaking up SUNWhea or of the value of trying to segregate private >> interfaces better. >> >> > I'm not of the opinion that breaking up SUNWhea into smaller packages is > useful. I *am* of the opinion that headers which are Project Private, > or possibly Consolidation Private, should not be packaged at all. (I'd > probably grant a special exception for Consolidation Private interfaces > which are *intended* for public consumption at some future date, but > even that could probably just as easily be dealt with by a future push > after ARC approves the interfaces for public consumption.) That's not how Sun has done things historically. Things are added to SUNWhea on project team whim. Sometimes headers that have nothing to do with anything at all (, anyone?) are delivered. Sometimes things that include private implementation details are there. It's a potpourri. The point of architecture isn't (and hasn't been) to keep "secrets;" it's to define what should and should not be used as a matter of _documentation_. The distinction is important. Finding a random file on the system doesn't give you any special guarantee that the contents won't blind you or drive you mad. Read through CR 4696464 for some of the history on this. > I suppose at one point having those headers on the system was useful for > debugging back when people had to manually work out structures in adb. > These days with CTF they are completely unnecessary. Whenever I easily > I can, I remove project private (especially *driver private!*) headers > from packaging. I think you're at least partly swimming against the tide. I agree that it'd be nice to have some clearer delineation, but outright removal isn't quite the norm. Only omitting *documentation* has been the norm. One other important use, besides adb, is for third party software that (knowingly or not) violates the undocumented interfaces. This is unfortunately extremely common, simply because the set of documented interfaces is a subset of the *NECESSARY* ones. And when faced with delivering a product for revenue versus obeying obscure architectural advice from Sun, guess which one wins? The system is unfortunately rife with this sort of stuff. The VM/VFS interfaces are just the tip of the iceberg. -- James Carlson 42.703N 71.076W From Alan.Coopersmith@sun.com Wed Sep 9 09:27:58 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n89GRw0q007771 for ; Wed, 9 Sep 2009 09:27:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n89GRvIL020544 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Sep 2009 10:27:57 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPP00F03PQLUT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 10:27:57 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPP0025XPQL3380@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 10:27:57 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n89GRvvn026993 for ; Wed, 09 Sep 2009 09:27:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPP00400PDV0J00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 09:27:56 -0700 (PDT) Received: from [129.145.155.53] ([unknown] [129.145.155.53]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPP000XXPQKER30@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 09:27:56 -0700 (PDT) Date: Wed, 09 Sep 2009 09:27:56 -0700 From: Alan Coopersmith Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA7CF72.4010702@sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore" Cc: James Carlson , Darren Reed , Gordon Ross , PSARC-ext@sun.com Message-id: <4AA7D78C.2050209@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> <4AA70A65.60903@sun.com> <4AA7C720.9060308@workingcode.com> <4AA7CF72.4010702@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 333 Garrett D'Amore wrote: > These days with CTF they are completely unnecessary. CTF is Consolidation Private, and only available to things built in the ON consolidation, so it's not a useful replacement for anything. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore@sun.com Wed Sep 9 11:03:49 2009 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 n89I3mYM011755 for ; Wed, 9 Sep 2009 11:03:48 -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 n89I3f7s006781 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Sep 2009 19:03:47 +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 <0KPP00105U6BXJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 11:03:47 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPP00GEKU6AYPD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 11:03:46 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n89I3kaF026317 for ; Wed, 09 Sep 2009 11:03:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPP00D00TG5H900@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 11:03:46 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPP00M8VU66RSD0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 11:03:43 -0700 (PDT) Date: Wed, 09 Sep 2009 11:03:42 -0700 From: "Garrett D'Amore" Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA7D78C.2050209@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: James Carlson , Darren Reed , Gordon Ross , PSARC-ext@sun.com Message-id: <4AA7EDFE.7050008@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> <4AA70A65.60903@sun.com> <4AA7C720.9060308@workingcode.com> <4AA7CF72.4010702@sun.com> <4AA7D78C.2050209@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 662 Alan Coopersmith wrote: > Garrett D'Amore wrote: > >> These days with CTF they are completely unnecessary. >> > > CTF is Consolidation Private, and only available to things built in > the ON consolidation, so it's not a useful replacement for anything. > > The drivers that are built in ON don't need to expose their header files, though. For example, what use is exposing a header file for afe? Approximately zero. So its not delivered. If you want to look at the internals, grab the full source code, instead of just a header file If you want to try to debug it, you can still use macros like $; Wed, 9 Sep 2009 11:13:21 -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 n89IDLre009906 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Sep 2009 11:13:21 -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 <0KPP00305UM74F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 12:13:19 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPP00135UM6KO10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 12:13:18 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n89IDIRh025988 for ; Wed, 09 Sep 2009 18:13:18 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPP00300TV6EB00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 12:13:18 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPP00AE8ULLRV60@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Sep 2009 12:12:57 -0600 (MDT) Date: Wed, 09 Sep 2009 14:10:52 -0400 From: Sebastien Roy Subject: Re: Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009] In-reply-to: <4AA7EDFE.7050008@sun.com> Sender: Sebastien.Roy@Sun.COM To: "Garrett D'Amore" Cc: Alan Coopersmith , Gordon Ross , PSARC-ext@Sun.COM, Darren Reed Message-id: <1252519852.23993.52.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.26.3 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909081610.n88GARbU017715@sac.sfbay.sun.com> <1252427524.1085.4.camel@dell6300gwr> <4AA6888A.1000704@sun.com> <4AA68CCB.90601@workingcode.com> <4AA68EA7.3010604@sun.com> <20090908171659.GB1033@Sun.COM> <4AA695C9.8040409@sun.com> <4AA698C4.5010808@workingcode.com> <4AA69AAD.1070006@sun.com> <4AA6F74E.2030607@Sun.COM> <4AA70A65.60903@sun.com> <4AA7C720.9060308@workingcode.com> <4AA7CF72.4010702@sun.com> <4AA7D78C.2050209@sun.com> <4AA7EDFE.7050008@sun.com> Status: RO Content-Length: 1081 On Wed, 2009-09-09 at 11:03 -0700, Garrett D'Amore wrote: > Alan Coopersmith wrote: > > Garrett D'Amore wrote: > > > >> These days with CTF they are completely unnecessary. > >> > > > > CTF is Consolidation Private, and only available to things built in > > the ON consolidation, so it's not a useful replacement for anything. > > > > > The drivers that are built in ON don't need to expose their header > files, though. For example, what use is exposing a header file for > afe? Approximately zero. So its not delivered. If you want to look at > the internals, grab the full source code, instead of just a header file > > If you want to try to debug it, you can still use macros like $ kmdb, thanks to CTF. This is a riveting debate, but at this point, it has little relevance to this case. This case has its +1 (and I'll add my own +1 now), and we're all in agreement that the existence of shouldn't affect this case as it stands. Let's move on please and have the philosophical header file discussion over at arc-discuss. -Seb From gdamore@sun.com Wed Sep 16 11:07:08 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8GI78kH009953 for ; Wed, 16 Sep 2009 11:07:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8GI75sm029947 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 16 Sep 2009 12:07:08 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ200C1JSZULC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 11:07:06 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ200BL0SZTPK10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 11:07:05 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8GI75r3010365 for ; Wed, 16 Sep 2009 11:07:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ200D00R4Y2500@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 11:07:05 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ200HE3SZR9M40@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 16 Sep 2009 11:07:03 -0700 (PDT) Date: Wed, 16 Sep 2009 11:07:03 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/476 Public linked lists Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <4AB12947.8080208@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 55 This case was approved at PSARC today. - Garrett