From gd78059@sac.sfbay.sun.com Fri Jul 24 14:05:05 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 n6OL55j5009964 for ; Fri, 24 Jul 2009 14:05:05 -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 n6OL51aA016099; Fri, 24 Jul 2009 14:05:05 -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 <0KNB0051V18FOE00@brm-avmta-1.central.sun.com>; Fri, 24 Jul 2009 15:05:03 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KNB00JV318E9Q60@brm-avmta-1.central.sun.com>; Fri, 24 Jul 2009 15:05:02 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6OL52bo018932; Fri, 24 Jul 2009 14:05:02 -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 n6OL51V6009959; Fri, 24 Jul 2009 14:05:01 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n6OL51QQ009955; Fri, 24 Jul 2009 14:05:01 -0700 (PDT) Date: Fri, 24 Jul 2009 14:05:01 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: Driver Private Minor Numbers for GLDv3 [PSARC/2009/413 FastTrack timeout 07/31/2009] To: PSARC-ext@sun.com Cc: networking-discuss@sun.com Message-id: <200907242105.n6OL51QQ009955@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5638 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: Driver Private Minor Numbers for GLDv3 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 24 July, 2009 4. Technical Description Driver Private Minor Numbers for GLDv3 -------------------------------------- Problem: If a device driver that is a GLDv3 mac provider desires to export additional minor nodes (such as for use with the techniques described in PSARC 2009/380), then the driver must be able to allocate minor numbers in a way that does not conflict with GLDv3's use of them. GLDv3 currently allocates minor numbers as follows: 0 is used for the special DLPI style 2 node, numbers 1-1000 are used for PPAs (minor = PPA + 1), and minor numbers from 1001 through MAXMIN32 are used for dynamic stream allocations. (Numbers above MAXMIN32 are effectively useless since minor numbers must be accessible to 32-bit applications.) Note that this latter range is shared across all device drivers using a global id_space_t. We are currently in the process of trying to engineer a driver that is both an InfiniBand HCA, and a GLDv3 ethernet provider. So the problem of minor number allocation is not merely a theoretical curiosity. Solution: We propose to constrain the range of minor numbers used by GLDv3 to just half that that it currently uses, leaving half of the minor numbers available for driver private use. We will also export the value that represents the first minor number available for driver private as the macro MAC_PRIVATE_MINOR. This will take the value 0x20000. Note that MAXMIN32 takes the value 0x3ffff. The construction of MAC_PRIVATE_MINOR is calculated from MAXMIN32: #define MAC_PRIVATE_MINOR ((MAXMIN32 + 1) / 2) This macro will be available in Imported Interfaces: +---------------------------------------------------------------------+ | Interface Commitment Level Comments | +---------------------------------------------------------------------+ | GLDv3 Consolidation Private Specifically the mac | | provider interfaces. | | MAXMIN32 Committed | +---------------------------------------------------------------------+ Exported Interfaces: +---------------------------------------------------------------------+ | Interface Commitment Level Comments | +---------------------------------------------------------------------+ | MAC_PRIVATE_MINOR Consolidation Private Start of driver private | | minor numbers. | +---------------------------------------------------------------------+ Limitations: This approach allows drivers like our hybrid ethernet/IB driver to be constructed. However, it does have one drawback, which is that there will only be about 130,000 possible concurrent streams that can be open against all GLDv3 devices at a time. This is roughly half the current number allowed. We don't think this is a limitation. If it becomes one, there is an alternate approach that can be used; see below. The other limitation is that this assumes that mac providers which need to have separate minor number management are not also participating in other frameworks which have the same minor number allocation issue. At the moment we are not aware of any such cases, but if the situation arises there is an alternate approach that can be used; see below. Ramifications for Mac Providers: Drivers that make use of this feature will have to do some additional work as well. Most obviously, they will need to provide an alternate implementation of getinfo(9e). They will also need to provide alternate implementations of open(9e) and possibly other functions as well, in the cb_ops and streamtab structures. The logical place for them to do this will be after calling mac_init_ops(). mac_init_ops() currently allocates storage on the heap for these structures, private to the driver, so such modifications can be made in drivers harmlessly. This behavior will have to become part of the interface specification for GLDv3 mac providers. Of course, current mac providers that don't need this functionality will not require any modification. Alternate Approach: An alternate way of solving this problem would be to give the ability to Mac providers to manage their own minor number spaces. This could be triggered by a capability. This heavier weight solution would be ultimately flexible, but would require more significant changes to the GLDv3. After discussion with several other engineers, we decided against using this approach at this time, because we didn't feel the complexity was needed, or is likely to be needed for the foreseeable future. One benefit of this atlernate approach, is that it could be used to provide per-driver minor number spaces, which could ease pressure on the minor number spaces, if such pressure is ever found to be a concern. However, we have a difficult time imagining a system where more than 100,000 concurrent mac clients would be in use. 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 gdamore@sun.com Fri Jul 24 14:11:40 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 n6OLBejf010203 for ; Fri, 24 Jul 2009 14:11:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6OLBcuT011432 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Jul 2009 14:11:40 -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 <0KNB0060T1JEEY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 15:11:39 -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 <0KNB00JFX1JE9V60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 15:11:38 -0600 (MDT) 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 n6OLBcck008817 for ; Fri, 24 Jul 2009 14:11:38 -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.02 64bit (built Apr 16 2009)) id <0KNB006001BZS700@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 14:11:38 -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.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNB00K071JCW3B0@fe-sfbay-09.sun.com>; Fri, 24 Jul 2009 14:11:36 -0700 (PDT) Date: Fri, 24 Jul 2009 14:11:36 -0700 From: "Garrett D'Amore" Subject: Re: Driver Private Minor Numbers for GLDv3 [PSARC/2009/413 FastTrack timeout 07/31/2009] In-reply-to: <200907242105.n6OL51QQ009955@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, networking-discuss Message-id: <4A6A2388.2000709@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: <200907242105.n6OL51QQ009955@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 6104 I botched the e-mail address for networking-discuss in sac_next case. I'm resending so they get it. Sorry for the duplicate for those of you who also get PSARC mail. -- Garrett 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: > Driver Private Minor Numbers for GLDv3 > 1.2. Name of Document Author/Supplier: > Author: Garrett D'Amore > 1.3 Date of This Document: > 24 July, 2009 > 4. Technical Description > > Driver Private Minor Numbers for GLDv3 > -------------------------------------- > > Problem: > > If a device driver that is a GLDv3 mac provider desires to export > additional minor nodes (such as for use with the techniques > described in PSARC 2009/380), then the driver must be able to > allocate minor numbers in a way that does not conflict with > GLDv3's use of them. > > GLDv3 currently allocates minor numbers as follows: 0 is used for > the special DLPI style 2 node, numbers 1-1000 are used for PPAs > (minor = PPA + 1), and minor numbers from 1001 through MAXMIN32 > are used for dynamic stream allocations. (Numbers above MAXMIN32 > are effectively useless since minor numbers must be accessible to > 32-bit applications.) Note that this latter range is shared > across all device drivers using a global id_space_t. > > We are currently in the process of trying to engineer a driver > that is both an InfiniBand HCA, and a GLDv3 ethernet provider. So > the problem of minor number allocation is not merely a theoretical > curiosity. > > Solution: > > We propose to constrain the range of minor numbers used by GLDv3 > to just half that that it currently uses, leaving half of the > minor numbers available for driver private use. We will also > export the value that represents the first minor number available > for driver private as the macro MAC_PRIVATE_MINOR. > > This will take the value 0x20000. Note that MAXMIN32 takes the > value 0x3ffff. The construction of MAC_PRIVATE_MINOR is > calculated from MAXMIN32: > > #define MAC_PRIVATE_MINOR ((MAXMIN32 + 1) / 2) > > This macro will be available in > > Imported Interfaces: > > +---------------------------------------------------------------------+ > | Interface Commitment Level Comments | > +---------------------------------------------------------------------+ > | GLDv3 Consolidation Private Specifically the mac | > | provider interfaces. | > | MAXMIN32 Committed | > +---------------------------------------------------------------------+ > > Exported Interfaces: > > +---------------------------------------------------------------------+ > | Interface Commitment Level Comments | > +---------------------------------------------------------------------+ > | MAC_PRIVATE_MINOR Consolidation Private Start of driver private | > | minor numbers. | > +---------------------------------------------------------------------+ > > Limitations: > > This approach allows drivers like our hybrid ethernet/IB driver to > be constructed. However, it does have one drawback, which is that > there will only be about 130,000 possible concurrent streams that > can be open against all GLDv3 devices at a time. This is roughly > half the current number allowed. We don't think this is a > limitation. If it becomes one, there is an alternate approach > that can be used; see below. > > The other limitation is that this assumes that mac providers which > need to have separate minor number management are not also > participating in other frameworks which have the same minor number > allocation issue. At the moment we are not aware of any such > cases, but if the situation arises there is an alternate approach > that can be used; see below. > > Ramifications for Mac Providers: > > Drivers that make use of this feature will have to do some > additional work as well. Most obviously, they will need to > provide an alternate implementation of getinfo(9e). They will > also need to provide alternate implementations of open(9e) and > possibly other functions as well, in the cb_ops and streamtab > structures. The logical place for them to do this will be after > calling mac_init_ops(). mac_init_ops() currently allocates > storage on the heap for these structures, private to the driver, > so such modifications can be made in drivers harmlessly. This > behavior will have to become part of the interface specification > for GLDv3 mac providers. > > Of course, current mac providers that don't need this > functionality will not require any modification. > > > Alternate Approach: > > An alternate way of solving this problem would be to give the > ability to Mac providers to manage their own minor number spaces. > This could be triggered by a capability. This heavier weight > solution would be ultimately flexible, but would require more > significant changes to the GLDv3. After discussion with several > other engineers, we decided against using this approach at this > time, because we didn't feel the complexity was needed, or is > likely to be needed for the foreseeable future. One benefit of > this atlernate approach, is that it could be used to provide > per-driver minor number spaces, which could ease pressure on the > minor number spaces, if such pressure is ever found to be a > concern. However, we have a difficult time imagining a system > where more than 100,000 concurrent mac clients would be in use. > > > 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 Sebastien.Roy@Sun.COM Fri Jul 24 20:11:26 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 n6P3BQvv029635 for ; Fri, 24 Jul 2009 20:11:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6P3BQYQ026517 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Jul 2009 20:11:26 -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 <0KNB00301I72OY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 21:11:26 -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 <0KNB002W7I71X270@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 21:11:25 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6P3BPTV022260 for ; Sat, 25 Jul 2009 03:11:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNB00900HYE9200@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Jul 2009 21:11:25 -0600 (MDT) Received: from [192.168.1.5] ([unknown] [173.76.18.185]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNB00MQQI71QK30@mail-amer.sun.com>; Fri, 24 Jul 2009 21:11:25 -0600 (MDT) Date: Fri, 24 Jul 2009 23:11:24 -0400 From: Sebastien Roy Subject: Re: Driver Private Minor Numbers for GLDv3 [PSARC/2009/413 FastTrack timeout 07/31/2009] In-reply-to: <200907242105.n6OL51QQ009955@sac.sfbay.sun.com> Sender: Sebastien.Roy@Sun.COM To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@Sun.COM, networking-discuss@opensolaris.org Message-id: <1248491484.102322.48.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.26.2 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907242105.n6OL51QQ009955@sac.sfbay.sun.com> Status: RO Content-Length: 384 +1, and one minor (no pun untended) nit: On Fri, 2009-07-24 at 14:05 -0700, Garrett D'Amore - sun microsystems wrote: > #define MAC_PRIVATE_MINOR ((MAXMIN32 + 1) / 2) > > This macro will be available in MAC_PRIVATE_MINOR_MIN might describe more clearly that minor numbers starting at this value and above are available for private use. -Seb From garrett@damore.org Sat Jul 25 18:55:28 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 n6Q1tRb1029126 for ; Sat, 25 Jul 2009 18:55:27 -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 n6Q1tJRv029326 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 26 Jul 2009 09:55:26 +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 <0KND001039CB9500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 25 Jul 2009 18:55:23 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KND00EWL9CAF190@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sat, 25 Jul 2009 18:55:22 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6Q1tMSv014338 for ; Sun, 26 Jul 2009 01:55:22 +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-963062 for PSARC-ext@Sun.COM; Sun, 26 Jul 2009 01:55:21 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-19756787 for PSARC-ext@Sun.COM; Sun, 26 Jul 2009 01:55:18 +0000 (Z) Received: from outbound-mail-131.bluehost.com ([67.222.39.21] [67.222.39.21]) by relay4i.sun.com id BT-MMP-21273401 for PSARC-ext@Sun.COM; Sun, 26 Jul 2009 01:55:18 +0000 (Z) Received: (qmail 22786 invoked by uid 0); Sun, 26 Jul 2009 01:55:17 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by outboundproxy4.bluehost.com with SMTP; Sun, 26 Jul 2009 01:55:17 +0000 Received: from sca-ea-fw-1.sun.com ([192.18.43.225] helo=[10.7.251.172]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MUsxJ-0007A4-07; Sat, 25 Jul 2009 19:55:17 -0600 Date: Sat, 25 Jul 2009 18:55:15 -0700 From: "Garrett D'Amore" Subject: Re: [networking-discuss] Driver Private Minor Numbers for GLDv3 [PSARC/2009/413 FastTrack timeout 07/31/2009] In-reply-to: <1248491484.102322.48.camel@seb> To: Sebastien Roy Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, networking-discuss@opensolaris.org Message-id: <4A6BB783.7030504@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=MB8gdixD9+9VTMcAeog+/5M3aheKuT/JMFsSSvYCva6YOpNBu00DcrwffzrpZj1yAknw0qRP6hhKN36iQaqT5tEcZp7tGq92we4tdkn97tbBRXXvRvc061nwEytPCNAv; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 192.18.43.225 authed with garrett+damore.org} X-Antispam: No, score=0.0/5.0, scanned in 3.066sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907242105.n6OL51QQ009955@sac.sfbay.sun.com> <1248491484.102322.48.camel@seb> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 796 Just one more note: This case is seeking *patch* binding, and I do intend to backport this change to Solaris 10 at some point. (I'll need this change to support the hardware driver I'm working on in Solaris 10.) - Garrett Sebastien Roy wrote: > +1, and one minor (no pun untended) nit: > > On Fri, 2009-07-24 at 14:05 -0700, Garrett D'Amore - sun microsystems > wrote: > >> #define MAC_PRIVATE_MINOR ((MAXMIN32 + 1) / 2) >> >> This macro will be available in >> > > MAC_PRIVATE_MINOR_MIN might describe more clearly that minor numbers > starting at this value and above are available for private use. > > -Seb > > > _______________________________________________ > networking-discuss mailing list > networking-discuss@opensolaris.org > From gdamore@sun.com Wed Jul 29 11:02: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 n6TI2kZH004032 for ; Wed, 29 Jul 2009 11:02:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6TI2bDT004070 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Jul 2009 12:02:45 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KNK00D3J24KUU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 29 Jul 2009 11:02:44 -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 <0KNK0058H24JBQB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 29 Jul 2009 11:02:43 -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 n6TI2hqx007110 for ; Wed, 29 Jul 2009 11:02:43 -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.02 64bit (built Apr 16 2009)) id <0KNK000001WRQG00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 29 Jul 2009 11:02:40 -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.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNK00GHQ246UVB0@fe-sfbay-09.sun.com>; Wed, 29 Jul 2009 11:02:31 -0700 (PDT) Date: Wed, 29 Jul 2009 11:02:30 -0700 From: "Garrett D'Amore" Subject: Re: Driver Private Minor Numbers for GLDv3 [PSARC/2009/413 FastTrack timeout 07/31/2009] In-reply-to: <1248491484.102322.48.camel@seb> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, networking-discuss@opensolaris.org Message-id: <4A708EB6.4020704@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: <200907242105.n6OL51QQ009955@sac.sfbay.sun.com> <1248491484.102322.48.camel@seb> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 55 This case was approved at PSARC today. - Garrett From gdamore@sun.com Fri Sep 25 07:13:50 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 n8PEDnVV005248 for ; Fri, 25 Sep 2009 07:13:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8PEDehs021376 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 25 Sep 2009 15:13:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ00A0366YBW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 25 Sep 2009 07:13:46 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00APM66X2Q10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 25 Sep 2009 07:13:45 -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 n8PEDjcs000042 for ; Fri, 25 Sep 2009 07:13:45 -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 <0KQJ007005ZK1000@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 25 Sep 2009 07:13:45 -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 <0KQJ00LRA66WUWA0@fe-sfbay-10.sun.com>; Fri, 25 Sep 2009 07:13:45 -0700 (PDT) Date: Fri, 25 Sep 2009 07:13:44 -0700 From: "Garrett D'Amore" Subject: Re: [networking-discuss] Driver Private Minor Numbers for GLDv3 [PSARC/2009/413 FastTrack timeout 07/31/2009] In-reply-to: <4A6BB783.7030504@damore.org> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore" Cc: Sebastien Roy , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, networking-discuss@opensolaris.org Message-id: <4ABCD018.7020509@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: <200907242105.n6OL51QQ009955@sac.sfbay.sun.com> <1248491484.102322.48.camel@seb> <4A6BB783.7030504@damore.org> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 805 I'd like to record a desire to change this case slightly. Rather than opening a new case, I'm going to just leave this here. Since there are no consumers for this API that have delivered yet, and its Consolidation Private, I think I can probably get away with just a small update to the case. If anyone feels that the following change warrants a regular fast track, please let me know and I'll file one. Instead of a macro MAC_PRIVATE_MINOR, I'd like to supply a function: minor_t mac_private_minor(void); The reason for the function call instead of a macro is to avoid hard coding a specific value into driver binaries, giving some ability to change the value if it is later needed, without forcing a recompile. For now the same numeric value is provided to drivers. -- Garrett