From sacadmin Fri Jun 15 10:42:51 2007 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 l5FHgp71001066; Fri, 15 Jun 2007 10:42:51 -0700 (PDT) Received: (from carlsonj@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l5FHgpk1001061; Fri, 15 Jun 2007 10:42:51 -0700 (PDT) Date: Fri, 15 Jun 2007 10:42:51 -0700 (PDT) From: James Carlson Message-Id: <200706151742.l5FHgpk1001061@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: ddi_modopen Stability Promotion [PSARC/2007/355 FastTrack timeout 06/22/2007] Status: RO Content-Length: 563 Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ddi_modopen Stability Promotion 1.2. Name of Document Author/Supplier: Author: Freeman Liu 1.3 Date of This Document: 15 June, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Fri Jun 15 10:45:41 2007 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 l5FHjfXX001091 for ; Fri, 15 Jun 2007 10:45:41 -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 l5FHi507020968; Fri, 15 Jun 2007 10:44:08 -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 <0JJO00K1VULJVX00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jun 2007 10:44:07 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJO00CLRULISK50@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jun 2007 10:44:06 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5FHi51r020551; Fri, 15 Jun 2007 13:44:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5FHi56s020548; Fri, 15 Jun 2007 13:44:05 -0400 (EDT) Date: Fri, 15 Jun 2007 13:44:05 -0400 From: James Carlson Subject: 2007/355 ddi_modopen Stability Promotion To: psarc-ext@sun.com Cc: Freeman Liu Message-id: <18034.53221.712594.998659@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 4913 I'm sponsoring this fast-track request for Freeman Liu. The timer is set to 06/22/2007. (A brief summary: 2005/050 interfaces are now Committed, patch/micro release binding.) Background Many hardware devices contain some software to function correctly. Traditionally, this piece of software was stored in non-volatile storage and thus called firmware. But recently, more and more hardware vendors replaced the non-volatile memory with volatile one to lower cost. For example, Intel 3945 wifi card and Intel wusb devices. And the "firmware", which comes in the form of an image file, now needs to be downloaded into the hardware before the hardware can fully function. Most of other main-stream OSes provide interfaces to access firmware in raw-data format. But the shortage of the raw-data format is that authentication check is not available. Therefore, we prefer to wrap the raw-data format firmware image in a kernel module so that we can sign and verify it by elfsign. In Solaris, the existing interfaces ddi_modopen, ddi_modsym and ddi_modclose serve this purpose very well. These interfaces have been used inside Sun for several cases including md, kcf and brandZ and are mature. However, these interfaces are private ones and can not be leveraged by hardware vendors and communities. This proposal is a follow up to "ddi_modopen dynamically access a loadable kernel module" (PSARC 2005/050). It is necessary to becoming familiar with that case to understand this issue. Competitive Analysis Windows provides interfaces to load firmware and sign at the package level. Windows requires all kernel components signed for the 64-bit platform. A signature can be stored in the .cat file of a package which contains the checksum of selected files in the packages. Linux adopts similar solution. For example, rpm provides signature function. Proposal We propose to make the interfaces ddi_modopen, ddi_modclose and ddi_modsym in 2005/050 Committed. We will use these interfaces to deliver separate firmware files on Solaris, and encourage other developers to use the interfaces in this way as well. Compared to other solutions, this proposal has many advantages. First, it can enable drivers to load and unload the image dynamically. This avoids unnecessary waste of ram. Second, because dependency can be set between drivers and the firmware image module, the potential boot device can rely on this to load firmware. Third, it can signed to ensure the authentication. This proposal requires a patch release binding so that it can be backported to S10 updates. But it will not be back ported to S9 and earlier version for the same reason mentioned in 2005/050 that doing that requires many of the module loading bugs fixed in s10 to be back ported too. Interfaces ------------------------------------------------------------------ Interface Name Stability Comments ------------------------------------------------------------------ KRTLD_MODE_FIRST Commited Mode argument to ddi_modopen(9F). ddi_modhandle_t Commited Opaque handle returned by ddi_modopen(9F). ddi_modopen(9F) Commited Peer of dlopen(3C) ddi_modsym(9F) Commited Peer of dlsym(3C) ddi_modclose(9F) Commited Peer of dlclose(3C) Prototypes (defined in modctl.h) #define KRTLD_MODE_FIRST 0x0001 typedef struct __ddi_modhandle *ddi_modhandle_t; extern ddi_modhandle_t ddi_modopen(const char *modname, int mode, int *errnop); extern void *ddi_modsym(ddi_modhandle_t handle, const char *symname, int *errnop); extern int ddi_modclose(ddi_modhandle_t handle); #pragma unknown_control_flow(ddi_modopen, ddi_modsym, ddi_modclose) Documentation Manpage for ddi_modopen, ddi_modsym and ddi_modclose will be added. A section about "Dynamic module access functions" will be added to Appendix B of "Writing Device Drivers". The dynamic way to fulfill the dependency of modules will be added to the section "Module dependencies" of Chapter 20 of "Writing Device Drivers". Boundary Condition This proposal does not cover the case to upgrade firmware in non-volatile memory, such as flash. That always needs to stop the hardware and the upgrade process is usually done by a program provided by vendor. This proposal does not provide ways to avoid name conflict between the firmware image module. The module provider should name it reasonably to avoid that. This proposal does not cover the case to load raw-data format firmware. Reference http://sac.sfbay/PSARC/2005/050/ RPM manpage: http://www.netadmintools.com/html/8rpm.man.html (Windows) Code Signing Best Practices: http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc From carlsonj@phorcys.east.sun.com Fri Jun 15 10:52:57 2007 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 l5FHqvMU001220 for ; Fri, 15 Jun 2007 10:52:57 -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 l5FHpM5u022733; Fri, 15 Jun 2007 10:51:22 -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 <0JJO00L0DUXKCB00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jun 2007 10:51:20 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJO00CE0UXHSP50@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jun 2007 10:51:17 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5FHpGTv020608; Fri, 15 Jun 2007 13:51:16 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5FHpGJg020605; Fri, 15 Jun 2007 13:51:16 -0400 (EDT) Date: Fri, 15 Jun 2007 13:51:16 -0400 From: James Carlson Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <18034.53221.712594.998659@gargle.gargle.HOWL> To: psarc-ext@sun.com Cc: Freeman Liu Message-id: <18034.53652.794197.637213@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> Status: RO Content-Length: 491 James Carlson writes: > I'm sponsoring this fast-track request for Freeman Liu. The timer is > set to 06/22/2007. (A brief summary: 2005/050 interfaces are now > Committed, patch/micro release binding.) Ignore my bad cc on the previous message; this one is right. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From edward.pilatowicz@sun.com Mon Jun 18 03:33:06 2007 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 l5IAX5NE006209 for ; Mon, 18 Jun 2007 03:33:05 -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 l5IAVHag001920; Mon, 18 Jun 2007 18:31:27 +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 <0JJT00B05UKCDI00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Jun 2007 03:31:24 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJT00DR7UKCRUD0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 18 Jun 2007 03:31:24 -0700 (PDT) Received: from mcescher.eng.sun.com (mcescher.SFBay.Sun.COM [129.146.224.55]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5IAVNIv015601; Mon, 18 Jun 2007 03:31:23 -0700 (PDT) Received: from mcescher.eng.sun.com (localhost [127.0.0.1]) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5IAVNV3910592; Mon, 18 Jun 2007 03:31:23 -0700 (PDT) Received: (from edp@localhost) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1/Submit) id l5IAVN1N910591; Mon, 18 Jun 2007 03:31:23 -0700 (PDT) Date: Mon, 18 Jun 2007 03:31:23 -0700 From: Edward Pilatowicz Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <18034.53221.712594.998659@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@sun.com, Freeman Liu Message-id: <20070618103123.GI909377@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> X-Authentication-warning: mcescher.eng.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 6273 so i have a few comments that mainly pertain to the documentation of this functionality for driver writers. the first is that since firmware will be deilvered wrapped in elf files, on x86 systems driver writers should deliver two copies of their firmware, one as a 32-bit elf file and the other as a 64-bit elf file. this should be explicity mentioned in the documentation. my second comment is that while i realize that one of the boundary conditions of this case is: This proposal does not provide ways to avoid name conflict between the firmware image module. The module provider should name it reasonably to avoid that. i still think that this case should provide advice for naming firmware files to driver writers. of example, should we create a firmware directory for all firware files? or should firmware files have the same name as the dirver but with some special extension? lastly, until new boot on sparc integrates, there is no public way for boot devices on sparc to access firmware files. the documentation should probably mention this limitation. ed On Fri, Jun 15, 2007 at 01:44:05PM -0400, James Carlson wrote: > I'm sponsoring this fast-track request for Freeman Liu. The timer is > set to 06/22/2007. (A brief summary: 2005/050 interfaces are now > Committed, patch/micro release binding.) > > > Background > > Many hardware devices contain some software to function correctly. > Traditionally, this piece of software was stored in non-volatile > storage and thus called firmware. But recently, more and more > hardware vendors replaced the non-volatile memory with volatile > one to lower cost. For example, Intel 3945 wifi card and Intel > wusb devices. And the "firmware", which comes in the form > of an image file, now needs to be downloaded into the hardware > before the hardware can fully function. > > Most of other main-stream OSes provide interfaces to access firmware > in raw-data format. But the shortage of the raw-data format is that > authentication check is not available. Therefore, we prefer to wrap > the raw-data format firmware image in a kernel module so that we can > sign and verify it by elfsign. > > In Solaris, the existing interfaces ddi_modopen, ddi_modsym and > ddi_modclose serve this purpose very well. These interfaces have been > used inside Sun for several cases including md, kcf and brandZ and are > mature. However, these interfaces are private ones and can not be > leveraged by hardware vendors and communities. > > This proposal is a follow up to "ddi_modopen dynamically > access a loadable kernel module" (PSARC 2005/050). It is > necessary to becoming familiar with that case to understand > this issue. > > Competitive Analysis > > Windows provides interfaces to load firmware and sign at the package > level. Windows requires all kernel components signed for the 64-bit > platform. A signature can be stored in the .cat file of a package > which contains the checksum of selected files in the packages. > > Linux adopts similar solution. For example, rpm provides signature > function. > > Proposal > > We propose to make the interfaces ddi_modopen, ddi_modclose and > ddi_modsym in 2005/050 Committed. > > We will use these interfaces to deliver separate firmware files on > Solaris, and encourage other developers to use the interfaces in this > way as well. > > Compared to other solutions, this proposal has many advantages. > First, it can enable drivers to load and unload the image dynamically. > This avoids unnecessary waste of ram. Second, because dependency can > be set between drivers and the firmware image module, the potential boot > device can rely on this to load firmware. Third, it can signed to > ensure the authentication. > > This proposal requires a patch release binding so that it can be > backported to S10 updates. But it will not be back ported to S9 > and earlier version for the same reason mentioned in 2005/050 that > doing that requires many of the module loading bugs fixed in s10 > to be back ported too. > > Interfaces > > ------------------------------------------------------------------ > Interface Name Stability Comments > ------------------------------------------------------------------ > > KRTLD_MODE_FIRST Commited Mode argument to > ddi_modopen(9F). > > ddi_modhandle_t Commited Opaque handle returned > by ddi_modopen(9F). > > ddi_modopen(9F) Commited Peer of dlopen(3C) > > ddi_modsym(9F) Commited Peer of dlsym(3C) > > ddi_modclose(9F) Commited Peer of dlclose(3C) > > Prototypes (defined in modctl.h) > > #define KRTLD_MODE_FIRST 0x0001 > > typedef struct __ddi_modhandle *ddi_modhandle_t; > > extern ddi_modhandle_t ddi_modopen(const char *modname, > int mode, int *errnop); > > extern void *ddi_modsym(ddi_modhandle_t handle, > const char *symname, int *errnop); > > extern int ddi_modclose(ddi_modhandle_t handle); > > #pragma unknown_control_flow(ddi_modopen, ddi_modsym, ddi_modclose) > > Documentation > Manpage for ddi_modopen, ddi_modsym and ddi_modclose will be added. > > A section about "Dynamic module access functions" will be added to > Appendix B of "Writing Device Drivers". > > The dynamic way to fulfill the dependency of modules will be added to > the section "Module dependencies" of Chapter 20 of "Writing Device > Drivers". > > Boundary Condition > This proposal does not cover the case to upgrade firmware in > non-volatile memory, such as flash. That always needs to stop > the hardware and the upgrade process is usually done by a program > provided by vendor. > > This proposal does not provide ways to avoid name conflict > between the firmware image module. The module provider should > name it reasonably to avoid that. > > This proposal does not cover the case to load raw-data format > firmware. > > Reference > http://sac.sfbay/PSARC/2005/050/ > RPM manpage: http://www.netadmintools.com/html/8rpm.man.html > (Windows) Code Signing Best Practices: http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc From edward.pilatowicz@Sun.COM Mon Jun 18 03:37:59 2007 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 l5IAbxxb006230 for ; Mon, 18 Jun 2007 03:37:59 -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 l5IAZkRc017452 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 18 Jun 2007 04:35:49 -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 <0JJT00B05USJSE00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 18 Jun 2007 03:36:19 -0700 (PDT) Received: from engmail4sca.SFBay.Sun.COM ([129.145.155.74]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJT00DAIUSJS0D0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 18 Jun 2007 03:36:19 -0700 (PDT) Received: from mcescher.eng.sun.com (mcescher.SFBay.Sun.COM [129.146.224.55]) by engmail4sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5IAaG9N016484; Mon, 18 Jun 2007 03:36:16 -0700 (PDT) Received: from mcescher.eng.sun.com (localhost [127.0.0.1]) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5IAaG6p910702; Mon, 18 Jun 2007 03:36:16 -0700 (PDT) Received: (from edp@localhost) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1/Submit) id l5IAaGrn910701; Mon, 18 Jun 2007 03:36:16 -0700 (PDT) Date: Mon, 18 Jun 2007 03:36:16 -0700 From: Edward Pilatowicz Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <18034.53221.712594.998659@gargle.gargle.HOWL> To: James Carlson Cc: psarc-ext@Sun.COM, Freeman Liu Message-id: <20070618103616.GA910663@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> X-Authentication-warning: mcescher.eng.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 6312 [ sigh. resending with correct cc. ] so i have a few comments that mainly pertain to the documentation of this functionality for driver writers. the first is that since firmware will be deilvered wrapped in elf files, on x86 systems driver writers should deliver two copies of their firmware, one as a 32-bit elf file and the other as a 64-bit elf file. this should be explicity mentioned in the documentation. my second comment is that while i realize that one of the boundary conditions of this case is: This proposal does not provide ways to avoid name conflict between the firmware image module. The module provider should name it reasonably to avoid that. i still think that this case should provide advice for naming firmware files to driver writers. of example, should we create a firmware directory for all firware files? or should firmware files have the same name as the dirver but with some special extension? lastly, until new boot on sparc integrates, there is no public way for boot devices on sparc to access firmware files. the documentation should probably mention this limitation. ed On Fri, Jun 15, 2007 at 01:44:05PM -0400, James Carlson wrote: > I'm sponsoring this fast-track request for Freeman Liu. The timer is > set to 06/22/2007. (A brief summary: 2005/050 interfaces are now > Committed, patch/micro release binding.) > > > Background > > Many hardware devices contain some software to function correctly. > Traditionally, this piece of software was stored in non-volatile > storage and thus called firmware. But recently, more and more > hardware vendors replaced the non-volatile memory with volatile > one to lower cost. For example, Intel 3945 wifi card and Intel > wusb devices. And the "firmware", which comes in the form > of an image file, now needs to be downloaded into the hardware > before the hardware can fully function. > > Most of other main-stream OSes provide interfaces to access firmware > in raw-data format. But the shortage of the raw-data format is that > authentication check is not available. Therefore, we prefer to wrap > the raw-data format firmware image in a kernel module so that we can > sign and verify it by elfsign. > > In Solaris, the existing interfaces ddi_modopen, ddi_modsym and > ddi_modclose serve this purpose very well. These interfaces have been > used inside Sun for several cases including md, kcf and brandZ and are > mature. However, these interfaces are private ones and can not be > leveraged by hardware vendors and communities. > > This proposal is a follow up to "ddi_modopen dynamically > access a loadable kernel module" (PSARC 2005/050). It is > necessary to becoming familiar with that case to understand > this issue. > > Competitive Analysis > > Windows provides interfaces to load firmware and sign at the package > level. Windows requires all kernel components signed for the 64-bit > platform. A signature can be stored in the .cat file of a package > which contains the checksum of selected files in the packages. > > Linux adopts similar solution. For example, rpm provides signature > function. > > Proposal > > We propose to make the interfaces ddi_modopen, ddi_modclose and > ddi_modsym in 2005/050 Committed. > > We will use these interfaces to deliver separate firmware files on > Solaris, and encourage other developers to use the interfaces in this > way as well. > > Compared to other solutions, this proposal has many advantages. > First, it can enable drivers to load and unload the image dynamically. > This avoids unnecessary waste of ram. Second, because dependency can > be set between drivers and the firmware image module, the potential boot > device can rely on this to load firmware. Third, it can signed to > ensure the authentication. > > This proposal requires a patch release binding so that it can be > backported to S10 updates. But it will not be back ported to S9 > and earlier version for the same reason mentioned in 2005/050 that > doing that requires many of the module loading bugs fixed in s10 > to be back ported too. > > Interfaces > > ------------------------------------------------------------------ > Interface Name Stability Comments > ------------------------------------------------------------------ > > KRTLD_MODE_FIRST Commited Mode argument to > ddi_modopen(9F). > > ddi_modhandle_t Commited Opaque handle returned > by ddi_modopen(9F). > > ddi_modopen(9F) Commited Peer of dlopen(3C) > > ddi_modsym(9F) Commited Peer of dlsym(3C) > > ddi_modclose(9F) Commited Peer of dlclose(3C) > > Prototypes (defined in modctl.h) > > #define KRTLD_MODE_FIRST 0x0001 > > typedef struct __ddi_modhandle *ddi_modhandle_t; > > extern ddi_modhandle_t ddi_modopen(const char *modname, > int mode, int *errnop); > > extern void *ddi_modsym(ddi_modhandle_t handle, > const char *symname, int *errnop); > > extern int ddi_modclose(ddi_modhandle_t handle); > > #pragma unknown_control_flow(ddi_modopen, ddi_modsym, ddi_modclose) > > Documentation > Manpage for ddi_modopen, ddi_modsym and ddi_modclose will be added. > > A section about "Dynamic module access functions" will be added to > Appendix B of "Writing Device Drivers". > > The dynamic way to fulfill the dependency of modules will be added to > the section "Module dependencies" of Chapter 20 of "Writing Device > Drivers". > > Boundary Condition > This proposal does not cover the case to upgrade firmware in > non-volatile memory, such as flash. That always needs to stop > the hardware and the upgrade process is usually done by a program > provided by vendor. > > This proposal does not provide ways to avoid name conflict > between the firmware image module. The module provider should > name it reasonably to avoid that. > > This proposal does not cover the case to load raw-data format > firmware. > > Reference > http://sac.sfbay/PSARC/2005/050/ > RPM manpage: http://www.netadmintools.com/html/8rpm.man.html > (Windows) Code Signing Best Practices: http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc From Freeman.Liu@sun.com Mon Jun 18 17:53:32 2007 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 l5J0rW8A026988 for ; Mon, 18 Jun 2007 17:53:32 -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 l5J0pOwm003499 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 18 Jun 2007 18:51:25 -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 <0JJU00L0FYEI9500@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 18 Jun 2007 17:51:54 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJU00048YEGLT70@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 18 Jun 2007 17:51:53 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5J0ppoZ011180 for ; Tue, 19 Jun 2007 00:51:51 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJU00501YAQY600@mail-apac.sun.com> (original mail from Freeman.Liu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 19 Jun 2007 08:51:51 +0800 (SGT) Received: from [129.158.218.121] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJU00D2NYEE95SZ@mail-apac.sun.com>; Tue, 19 Jun 2007 08:51:50 +0800 (SGT) Date: Tue, 19 Jun 2007 08:51:36 +0800 From: Freeman.Liu@sun.com Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <20070618103616.GA910663@eng.sun.com> Sender: Freeman.Liu@sun.com To: Edward Pilatowicz Cc: James Carlson , psarc-ext@sun.com, Freeman Message-id: <46772898.9020906@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7.5) Gecko/20041221 Status: RO Content-Length: 6935 Edward Pilatowicz wrote: >[ sigh. resending with correct cc. ] > >so i have a few comments that mainly pertain to the documentation >of this functionality for driver writers. > >the first is that since firmware will be deilvered wrapped in elf >files, on x86 systems driver writers should deliver two copies >of their firmware, one as a 32-bit elf file and the other as a 64-bit >elf file. this should be explicity mentioned in the documentation. > > Yes. That's right. And James, how can I add that information into the proposal ? >my second comment is that while i realize that one of the boundary >conditions of this case is: > > This proposal does not provide ways to avoid name conflict > between the firmware image module. The module provider should > name it reasonably to avoid that. > >i still think that this case should provide advice for naming firmware >files to driver writers. of example, should we create a firmware >directory for all firware files? or should firmware files have the >same name as the dirver but with some special extension? > > It will be good if we can work out universal naming scheme for all these firmware modules (or even all the modules). But I dont think we are experienced enough to make it. I prefer leaving it to driver writers now and picking it up when we get more experiences here. >lastly, until new boot on sparc integrates, there is no public way for >boot devices on sparc to access firmware files. the documentation >should probably mention this limitation. > > For ddi_modopen, it is correct. However, you can make the driver depend on the firmware module and the krtld will handle it. Thank you --Freeman >ed > >On Fri, Jun 15, 2007 at 01:44:05PM -0400, James Carlson wrote: > > >>I'm sponsoring this fast-track request for Freeman Liu. The timer is >>set to 06/22/2007. (A brief summary: 2005/050 interfaces are now >>Committed, patch/micro release binding.) >> >> >>Background >> >> Many hardware devices contain some software to function correctly. >> Traditionally, this piece of software was stored in non-volatile >> storage and thus called firmware. But recently, more and more >> hardware vendors replaced the non-volatile memory with volatile >> one to lower cost. For example, Intel 3945 wifi card and Intel >> wusb devices. And the "firmware", which comes in the form >> of an image file, now needs to be downloaded into the hardware >> before the hardware can fully function. >> >> Most of other main-stream OSes provide interfaces to access firmware >> in raw-data format. But the shortage of the raw-data format is that >> authentication check is not available. Therefore, we prefer to wrap >> the raw-data format firmware image in a kernel module so that we can >> sign and verify it by elfsign. >> >> In Solaris, the existing interfaces ddi_modopen, ddi_modsym and >> ddi_modclose serve this purpose very well. These interfaces have been >> used inside Sun for several cases including md, kcf and brandZ and are >> mature. However, these interfaces are private ones and can not be >> leveraged by hardware vendors and communities. >> >> This proposal is a follow up to "ddi_modopen dynamically >> access a loadable kernel module" (PSARC 2005/050). It is >> necessary to becoming familiar with that case to understand >> this issue. >> >>Competitive Analysis >> >> Windows provides interfaces to load firmware and sign at the package >> level. Windows requires all kernel components signed for the 64-bit >> platform. A signature can be stored in the .cat file of a package >> which contains the checksum of selected files in the packages. >> >> Linux adopts similar solution. For example, rpm provides signature >> function. >> >>Proposal >> >> We propose to make the interfaces ddi_modopen, ddi_modclose and >> ddi_modsym in 2005/050 Committed. >> >> We will use these interfaces to deliver separate firmware files on >> Solaris, and encourage other developers to use the interfaces in this >> way as well. >> >> Compared to other solutions, this proposal has many advantages. >> First, it can enable drivers to load and unload the image dynamically. >> This avoids unnecessary waste of ram. Second, because dependency can >> be set between drivers and the firmware image module, the potential boot >> device can rely on this to load firmware. Third, it can signed to >> ensure the authentication. >> >> This proposal requires a patch release binding so that it can be >> backported to S10 updates. But it will not be back ported to S9 >> and earlier version for the same reason mentioned in 2005/050 that >> doing that requires many of the module loading bugs fixed in s10 >> to be back ported too. >> >>Interfaces >> >> ------------------------------------------------------------------ >> Interface Name Stability Comments >> ------------------------------------------------------------------ >> >> KRTLD_MODE_FIRST Commited Mode argument to >> ddi_modopen(9F). >> >> ddi_modhandle_t Commited Opaque handle returned >> by ddi_modopen(9F). >> >> ddi_modopen(9F) Commited Peer of dlopen(3C) >> >> ddi_modsym(9F) Commited Peer of dlsym(3C) >> >> ddi_modclose(9F) Commited Peer of dlclose(3C) >> >>Prototypes (defined in modctl.h) >> >> #define KRTLD_MODE_FIRST 0x0001 >> >> typedef struct __ddi_modhandle *ddi_modhandle_t; >> >> extern ddi_modhandle_t ddi_modopen(const char *modname, >> int mode, int *errnop); >> >> extern void *ddi_modsym(ddi_modhandle_t handle, >> const char *symname, int *errnop); >> >> extern int ddi_modclose(ddi_modhandle_t handle); >> >> #pragma unknown_control_flow(ddi_modopen, ddi_modsym, ddi_modclose) >> >>Documentation >> Manpage for ddi_modopen, ddi_modsym and ddi_modclose will be added. >> >> A section about "Dynamic module access functions" will be added to >> Appendix B of "Writing Device Drivers". >> >> The dynamic way to fulfill the dependency of modules will be added to >> the section "Module dependencies" of Chapter 20 of "Writing Device >> Drivers". >> >>Boundary Condition >> This proposal does not cover the case to upgrade firmware in >> non-volatile memory, such as flash. That always needs to stop >> the hardware and the upgrade process is usually done by a program >> provided by vendor. >> >> This proposal does not provide ways to avoid name conflict >> between the firmware image module. The module provider should >> name it reasonably to avoid that. >> >> This proposal does not cover the case to load raw-data format >> firmware. >> >>Reference >> http://sac.sfbay/PSARC/2005/050/ >> RPM manpage: http://www.netadmintools.com/html/8rpm.man.html >> (Windows) Code Signing Best Practices: http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc >> >> From Tzongyu.Lee@sun.com Tue Jun 19 00:43:54 2007 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 l5J7hru2003739 for ; Tue, 19 Jun 2007 00:43:53 -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 l5J7g3HJ019180 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 19 Jun 2007 15:42:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJV00501HEFLZ00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 19 Jun 2007 00:42:15 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJV001IIHEETY30@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 19 Jun 2007 00:42:15 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5J7gDaf014830 for ; Tue, 19 Jun 2007 07:42:13 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJV00401HB9ZN00@mail-apac.sun.com> (original mail from Tzongyu.Lee@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 19 Jun 2007 15:42:13 +0800 (SGT) Received: from [129.158.218.85] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJV00DK3HEC94V9@mail-apac.sun.com>; Tue, 19 Jun 2007 15:42:13 +0800 (SGT) Date: Tue, 19 Jun 2007 15:41:26 +0800 From: Tzongyu Paul Lee Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <46772898.9020906@Sun.COM> Sender: Tzongyu.Lee@sun.com To: Freeman.Liu@sun.com Cc: Edward Pilatowicz , James Carlson , psarc-ext@sun.com Message-id: <467788A6.4080908@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: zh-cn, en-us, en X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> <46772898.9020906@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 8392 Freeman.Liu@Sun.COM wrote: > Edward Pilatowicz wrote: > >> [ sigh. resending with correct cc. ] >> >> so i have a few comments that mainly pertain to the documentation >> of this functionality for driver writers. >> >> the first is that since firmware will be deilvered wrapped in elf >> files, on x86 systems driver writers should deliver two copies >> of their firmware, one as a 32-bit elf file and the other as a 64-bit >> elf file. this should be explicity mentioned in the documentation. >> >> > Yes. That's right. And James, how can I add that information into the > proposal ? You can revise the proposal (while saving the original some simple convention *.orig), and when you sense convergence, provide the diff to all for a final round of consensus. This item is not contraversial and you should not expect problems. > >> my second comment is that while i realize that one of the boundary >> conditions of this case is: >> >> This proposal does not provide ways to avoid name conflict >> between the firmware image module. The module provider should >> name it reasonably to avoid that. >> >> i still think that this case should provide advice for naming firmware >> files to driver writers. of example, should we create a firmware >> directory for all firware files? or should firmware files have the >> same name as the dirver but with some special extension? >> >> > It will be good if we can work out universal naming scheme for all > these firmware modules (or even all > the modules). But I dont think we are experienced enough to make it. > I prefer leaving it to driver writers now > and picking it up when we get more experiences here. I would suggest that you take some leadership to avoid potential name space pollution that is hard to undo later. The suggestion of using driver name as prefix with special _extension is quite reasonable. I like the idea. We are counting on the disambiguating power of driver name, and that's a good start. You can recommend the use of of version/date/descriptive word to driver writers to manage their own name space as they see fit. > >> lastly, until new boot on sparc integrates, there is no public way for >> boot devices on sparc to access firmware files. the documentation >> should probably mention this limitation. >> >> > For ddi_modopen, it is correct. However, you can make the driver > depend on the firmware module and > the krtld will handle it. > > Thank you > --Freeman > >> ed >> >> On Fri, Jun 15, 2007 at 01:44:05PM -0400, James Carlson wrote: >> >> >>> I'm sponsoring this fast-track request for Freeman Liu. The timer is >>> set to 06/22/2007. (A brief summary: 2005/050 interfaces are now >>> Committed, patch/micro release binding.) >>> >>> >>> Background >>> >>> Many hardware devices contain some software to function correctly. >>> Traditionally, this piece of software was stored in non-volatile >>> storage and thus called firmware. But recently, more and more >>> hardware vendors replaced the non-volatile memory with volatile >>> one to lower cost. For example, Intel 3945 wifi card and Intel >>> wusb devices. And the "firmware", which comes in the form >>> of an image file, now needs to be downloaded into the hardware >>> before the hardware can fully function. >>> >>> Most of other main-stream OSes provide interfaces to access >>> firmware >>> in raw-data format. But the shortage of the raw-data format is that >>> authentication check is not available. Therefore, we prefer to wrap >>> the raw-data format firmware image in a kernel module so that we >>> can >>> sign and verify it by elfsign. >>> >>> In Solaris, the existing interfaces ddi_modopen, ddi_modsym and >>> ddi_modclose serve this purpose very well. These interfaces have >>> been >>> used inside Sun for several cases including md, kcf and brandZ >>> and are >>> mature. However, these interfaces are private ones and can not be >>> leveraged by hardware vendors and communities. >>> >>> This proposal is a follow up to "ddi_modopen dynamically >>> access a loadable kernel module" (PSARC 2005/050). It is >>> necessary to becoming familiar with that case to understand >>> this issue. >>> >>> Competitive Analysis >>> >>> Windows provides interfaces to load firmware and sign at the >>> package >>> level. Windows requires all kernel components signed for the 64-bit >>> platform. A signature can be stored in the .cat file of a package >>> which contains the checksum of selected files in the packages. >>> >>> Linux adopts similar solution. For example, rpm provides signature >>> function. >>> >>> Proposal >>> >>> We propose to make the interfaces ddi_modopen, ddi_modclose and >>> ddi_modsym in 2005/050 Committed. >>> >>> We will use these interfaces to deliver separate firmware files on >>> Solaris, and encourage other developers to use the interfaces in >>> this >>> way as well. >>> >>> Compared to other solutions, this proposal has many advantages. >>> First, it can enable drivers to load and unload the image >>> dynamically. >>> This avoids unnecessary waste of ram. Second, because dependency >>> can >>> be set between drivers and the firmware image module, the >>> potential boot >>> device can rely on this to load firmware. Third, it can signed to >>> ensure the authentication. >>> >>> This proposal requires a patch release binding so that it can be >>> backported to S10 updates. But it will not be back ported to S9 >>> and earlier version for the same reason mentioned in 2005/050 that >>> doing that requires many of the module loading bugs fixed in s10 >>> to be back ported too. >>> >>> Interfaces >>> >>> ------------------------------------------------------------------ >>> Interface Name Stability Comments >>> ------------------------------------------------------------------ >>> >>> KRTLD_MODE_FIRST Commited Mode argument to >>> ddi_modopen(9F). >>> >>> ddi_modhandle_t Commited Opaque handle returned >>> by ddi_modopen(9F). >>> >>> ddi_modopen(9F) Commited Peer of dlopen(3C) >>> >>> ddi_modsym(9F) Commited Peer of dlsym(3C) >>> >>> ddi_modclose(9F) Commited Peer of dlclose(3C) >>> >>> Prototypes (defined in modctl.h) >>> >>> #define KRTLD_MODE_FIRST 0x0001 >>> >>> typedef struct __ddi_modhandle *ddi_modhandle_t; >>> >>> extern ddi_modhandle_t ddi_modopen(const char *modname, >>> int mode, int *errnop); >>> >>> extern void *ddi_modsym(ddi_modhandle_t handle, >>> const char *symname, int *errnop); >>> >>> extern int ddi_modclose(ddi_modhandle_t handle); >>> >>> #pragma unknown_control_flow(ddi_modopen, ddi_modsym, ddi_modclose) >>> >>> Documentation >>> Manpage for ddi_modopen, ddi_modsym and ddi_modclose will be added. >>> >>> A section about "Dynamic module access functions" will be added to >>> Appendix B of "Writing Device Drivers". >>> >>> The dynamic way to fulfill the dependency of modules will be >>> added to >>> the section "Module dependencies" of Chapter 20 of "Writing Device >>> Drivers". >>> >>> Boundary Condition >>> This proposal does not cover the case to upgrade firmware in >>> non-volatile memory, such as flash. That always needs to stop >>> the hardware and the upgrade process is usually done by a program >>> provided by vendor. >>> >>> This proposal does not provide ways to avoid name conflict >>> between the firmware image module. The module provider should >>> name it reasonably to avoid that. >>> >>> This proposal does not cover the case to load raw-data format >>> firmware. >>> >>> Reference >>> http://sac.sfbay/PSARC/2005/050/ >>> RPM manpage: http://www.netadmintools.com/html/8rpm.man.html >>> (Windows) Code Signing Best Practices: >>> http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc >>> >>> >> > -- Tzongyu Paul Lee, Tzongyu.Lee@Sun.Com or Paul.Lee@Sun.COM BJS05 7225, x84343 From carlsonj@phorcys.east.sun.com Tue Jun 19 03:53:52 2007 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 l5JArqsY007310 for ; Tue, 19 Jun 2007 03:53:52 -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 l5JApfUe036210; Tue, 19 Jun 2007 04:51:42 -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 <0JJV00E0HQ6ZQ600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 19 Jun 2007 03:52:11 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJV006XXQ6ZYB70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 19 Jun 2007 03:52:11 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5JAqAjF028797; Tue, 19 Jun 2007 06:52:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5JAqAWg028794; Tue, 19 Jun 2007 06:52:10 -0400 (EDT) Date: Tue, 19 Jun 2007 06:52:10 -0400 From: James Carlson Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <467788A6.4080908@Sun.COM> To: Tzongyu Paul Lee Cc: Freeman.Liu@sun.com, psarc-ext@sun.com, Edward Pilatowicz Message-id: <18039.46426.845349.920152@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> <46772898.9020906@Sun.COM> <467788A6.4080908@Sun.COM> Status: RO Content-Length: 2181 Tzongyu Paul Lee writes: > I would suggest that you take some leadership to avoid potential name > space pollution > that is hard to undo later. > The suggestion of using driver name as prefix with special _extension is > quite reasonable. > I like the idea. > We are counting on the disambiguating power of driver name, and that's a > good start. > You can recommend the use of of version/date/descriptive word to driver > writers to manage > their own name space as they see fit. I would not suggest baking version numbers or (worse) dates into path names unless there's a _really_ good reason to do so. Merely disambiguating modules is not a "good reason." (On the other hand, if we had a magical kernel that could deal with multiple versions of the same module on the system at the same time, then that'd be a good reason.) The original 2005/050 case had a proposal for the naming scheme and, though I asked the submitter of this case about it, I'm really not clear on why this wasn't just brought forward: [_]_[.] For legacy Sun-developed plug-in 'misc' modules the stock-symbol is optional, new Sun-developed modules and third party modules should specify their stock-symbol (SUNW, etc) to avoid name conflicts. If there is only one consumer then may be the consuming (svm's meta disk driver (md(7D) would use "md"), otherwise a more generic name should be used to express purpose. The field describes what variation of an interface is implemented by the plug-in (the legacy "md_mirror" module implements mirroring below the "md" driver). The field is optional, it might be used if programmer decides to implement by-mod-name versioning. (Personally, I'd lose the "" goop here, as it only adds to the potential for disaster, but if it's only a recommendation, I'm slightly less concerned.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Tue Jun 19 03:56:32 2007 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 l5JAuWJ7007665 for ; Tue, 19 Jun 2007 03:56: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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5JAsp7X024662; Tue, 19 Jun 2007 11:54:51 +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 <0JJV00F03QBECA00@brm-avmta-1.central.sun.com>; Tue, 19 Jun 2007 04:54:50 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJV0073TQBEJU60@brm-avmta-1.central.sun.com>; Tue, 19 Jun 2007 04:54:50 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5JAsoQB028803; Tue, 19 Jun 2007 06:54:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5JAsnl0028800; Tue, 19 Jun 2007 06:54:49 -0400 (EDT) Date: Tue, 19 Jun 2007 06:54:49 -0400 From: James Carlson Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <46772898.9020906@Sun.COM> To: Freeman.Liu@Sun.COM Cc: Edward Pilatowicz , psarc-ext@Sun.COM Message-id: <18039.46585.940838.714965@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> <46772898.9020906@Sun.COM> Status: RO Content-Length: 577 Freeman.Liu@Sun.COM writes: > Yes. That's right. And James, how can I add that information into the > proposal ? Once the discussion has settled (I think it has), just draft up a new copy of the proposal and post it to psarc-ext@sun.com with the same subject line. Please start with the one I posted, as I fixed a few minor errors before submission. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Chris.Horne@sun.com Tue Jun 19 20:54:01 2007 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 l5K3s1kv001486 for ; Tue, 19 Jun 2007 20:54:01 -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 l5K3qNXm002573 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 19 Jun 2007 20:52:23 -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 <0JJX00F0B1F98000@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 19 Jun 2007 20:52:21 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJX0039S1F8HS50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 19 Jun 2007 20:52:20 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5K3qJUM025197 for ; Wed, 20 Jun 2007 03:52:19 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJX00B011E10J00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 19 Jun 2007 21:52:19 -0600 (MDT) Received: from [172.20.25.50] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJX00BWB1F7W0W6@mail-amer.sun.com>; Tue, 19 Jun 2007 21:52:19 -0600 (MDT) Date: Tue, 19 Jun 2007 21:51:12 -0600 From: Chris Horne Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <18039.46426.845349.920152@gargle.gargle.HOWL> Sender: Chris.Horne@sun.com To: James Carlson Cc: Tzongyu Paul Lee , Freeman.Liu@sun.com, psarc-ext@sun.com, Edward Pilatowicz Message-id: <4678A430.60006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> <46772898.9020906@Sun.COM> <467788A6.4080908@Sun.COM> <18039.46426.845349.920152@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 3183 The reason I did not push naming in the original case was because it is easy to get wrong, esp if you don't have much use experience. We have some more experience now. For driver use, my recommendation is to fix 6504975 ddi_modopen should allow open in subdirectory and tell people to deliver into a directory in misc that has the same name as the driver. This is what we plan to do as part of opensource for mpxio/scsi_vhci. -Chris # modinfo | grep scsi_vhci 22 13db490 1a0e8 189 1 scsi_vhci (SCSI VHCI Driver 1.65) 24 13f5378 1318 - 1 scsi_vhci_f_asym_sun (f_asym_sun 1.28) 25 13f65c0 34d8 - 1 scsi_vhci_f_asym_lsi (f_asym_lsi 1.28) 26 13f9860 2630 - 1 scsi_vhci_f_asym_emc (f_asym_emc 1.28) 27 13fbda8 3f8 - 1 scsi_vhci_f_sym_emc (f_sym_emc 1.3) 28 13fc0d0 588 - 1 scsi_vhci_f_sym (f_sym 1.28) 29 13fc510 3148 - 1 scsi_vhci_f_tpgs (f_tpgs 1.28) # ls -R /kernel/misc/scsi_vhci /kernel/misc/scsi_vhci: sparcv9 /kernel/misc/scsi_vhci/sparcv9: scsi_vhci_f_asym_emc scsi_vhci_f_asym_sun scsi_vhci_f_sym_emc scsi_vhci_f_asym_lsi scsi_vhci_f_sym scsi_vhci_f_tpgs # find /kernel/drv -name scsi_vhci -print /kernel/drv/sparcv9/scsi_vhci > Tzongyu Paul Lee writes: > >> I would suggest that you take some leadership to avoid potential name >> space pollution >> that is hard to undo later. >> The suggestion of using driver name as prefix with special _extension is >> quite reasonable. >> I like the idea. >> We are counting on the disambiguating power of driver name, and that's a >> good start. >> You can recommend the use of of version/date/descriptive word to driver >> writers to manage >> their own name space as they see fit. >> > > I would not suggest baking version numbers or (worse) dates into path > names unless there's a _really_ good reason to do so. Merely > disambiguating modules is not a "good reason." (On the other hand, if > we had a magical kernel that could deal with multiple versions of the > same module on the system at the same time, then that'd be a good > reason.) > > The original 2005/050 case had a proposal for the naming scheme and, > though I asked the submitter of this case about it, I'm really not > clear on why this wasn't just brought forward: > > [_]_[.] > > For legacy Sun-developed plug-in 'misc' modules the stock-symbol is > optional, new Sun-developed modules and third party modules should > specify their stock-symbol (SUNW, etc) to avoid name conflicts. If > there is only one consumer then may be the consuming > (svm's meta disk driver (md(7D) would use "md"), > otherwise a more generic name should be used to express purpose. > The field describes what variation of an interface is > implemented by the plug-in (the legacy "md_mirror" module > implements mirroring below the "md" driver). The field is > optional, it might be used if programmer decides to implement > by-mod-name versioning. > > (Personally, I'd lose the "" goop here, as it only adds to > the potential for disaster, but if it's only a recommendation, I'm > slightly less concerned.) > > From edward.pilatowicz@sun.com Wed Jun 20 00:55:08 2007 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 l5K7t7Ys007818 for ; Wed, 20 Jun 2007 00:55:08 -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 l5K7rL0h004105 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 20 Jun 2007 15:53:29 +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 <0JJX00H1PCL34400@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jun 2007 00:53:27 -0700 (PDT) Received: from engmail4sca.SFBay.Sun.COM ([129.145.155.74]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJX00393CL2I0F0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jun 2007 00:53:26 -0700 (PDT) Received: from mcescher.eng.sun.com (mcescher.SFBay.Sun.COM [129.146.224.55]) by engmail4sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5K7rNCU029202; Wed, 20 Jun 2007 00:53:23 -0700 (PDT) Received: from mcescher.eng.sun.com (localhost [127.0.0.1]) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5K7rNsT940734; Wed, 20 Jun 2007 00:53:23 -0700 (PDT) Received: (from edp@localhost) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1/Submit) id l5K7rNZM940733; Wed, 20 Jun 2007 00:53:23 -0700 (PDT) Date: Wed, 20 Jun 2007 00:53:23 -0700 From: Edward Pilatowicz Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <4678A430.60006@sun.com> To: Chris Horne Cc: James Carlson , Tzongyu Paul Lee , Freeman.Liu@sun.com, psarc-ext@sun.com Message-id: <20070620075323.GA940478@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> <46772898.9020906@Sun.COM> <467788A6.4080908@Sun.COM> <18039.46426.845349.920152@gargle.gargle.HOWL> <4678A430.60006@sun.com> X-Authentication-warning: mcescher.eng.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 3940 but in your example below, are you delivering firmware in these misc modules? or are these misc modules essentially modular plugins for the scsi_vhci driver? (i thought they were the latter.) this arc case was proposing that the promotion of ddi_modopen() and friends was for the specific purpose of loading hardware firmware modules, but there would be no reason that driver writers wouldn't be able to use these interfaces for modularization purposes as well, in which case it seems that the documentation for these interfaces should provide some module naming advice for both scenarios. ed On Tue, Jun 19, 2007 at 09:51:12PM -0600, Chris Horne wrote: > The reason I did not push naming in the original case > was because it is easy to get wrong, esp if you don't > have much use experience. We have some more > experience now. > > For driver use, my recommendation is to fix > > 6504975 ddi_modopen should allow open in subdirectory > > and tell people to deliver into a directory in misc that has the same > name as the driver. This is what we plan to do as part of > opensource for mpxio/scsi_vhci. > > -Chris > > # modinfo | grep scsi_vhci > 22 13db490 1a0e8 189 1 scsi_vhci (SCSI VHCI Driver 1.65) > 24 13f5378 1318 - 1 scsi_vhci_f_asym_sun (f_asym_sun 1.28) > 25 13f65c0 34d8 - 1 scsi_vhci_f_asym_lsi (f_asym_lsi 1.28) > 26 13f9860 2630 - 1 scsi_vhci_f_asym_emc (f_asym_emc 1.28) > 27 13fbda8 3f8 - 1 scsi_vhci_f_sym_emc (f_sym_emc 1.3) > 28 13fc0d0 588 - 1 scsi_vhci_f_sym (f_sym 1.28) > 29 13fc510 3148 - 1 scsi_vhci_f_tpgs (f_tpgs 1.28) > # ls -R /kernel/misc/scsi_vhci > /kernel/misc/scsi_vhci: > sparcv9 > > /kernel/misc/scsi_vhci/sparcv9: > scsi_vhci_f_asym_emc scsi_vhci_f_asym_sun scsi_vhci_f_sym_emc > scsi_vhci_f_asym_lsi scsi_vhci_f_sym scsi_vhci_f_tpgs > # find /kernel/drv -name scsi_vhci -print > /kernel/drv/sparcv9/scsi_vhci > > > >Tzongyu Paul Lee writes: > > > >>I would suggest that you take some leadership to avoid potential name > >>space pollution > >>that is hard to undo later. > >>The suggestion of using driver name as prefix with special _extension is > >>quite reasonable. > >>I like the idea. > >>We are counting on the disambiguating power of driver name, and that's a > >>good start. > >>You can recommend the use of of version/date/descriptive word to driver > >>writers to manage > >>their own name space as they see fit. > >> > > > >I would not suggest baking version numbers or (worse) dates into path > >names unless there's a _really_ good reason to do so. Merely > >disambiguating modules is not a "good reason." (On the other hand, if > >we had a magical kernel that could deal with multiple versions of the > >same module on the system at the same time, then that'd be a good > >reason.) > > > >The original 2005/050 case had a proposal for the naming scheme and, > >though I asked the submitter of this case about it, I'm really not > >clear on why this wasn't just brought forward: > > > > [_]_[.] > > > > For legacy Sun-developed plug-in 'misc' modules the stock-symbol is > > optional, new Sun-developed modules and third party modules should > > specify their stock-symbol (SUNW, etc) to avoid name conflicts. If > > there is only one consumer then may be the consuming > > (svm's meta disk driver (md(7D) would use "md"), > > otherwise a more generic name should be used to express purpose. > > The field describes what variation of an interface is > > implemented by the plug-in (the legacy "md_mirror" module > > implements mirroring below the "md" driver). The field is > > optional, it might be used if programmer decides to implement > > by-mod-name versioning. > > > >(Personally, I'd lose the "" goop here, as it only adds to > >the potential for disaster, but if it's only a recommendation, I'm > >slightly less concerned.) > > > > From Chris.Horne@Sun.COM Wed Jun 20 07:12:59 2007 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 l5KECwmT016799 for ; Wed, 20 Jun 2007 07:12:58 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5KEBGGM022425 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 20 Jun 2007 15:11:19 +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 <0JJX00701U2T9500@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jun 2007 07:11:17 -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 <0JJX00JHIU2TWE60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jun 2007 07:11:17 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5KEBGL4019793 for ; Wed, 20 Jun 2007 14:11:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJX00A01TGW8N00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 20 Jun 2007 08:11:16 -0600 (MDT) Received: from sun.com ([129.150.33.93]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJX00DWRU2PBF50@mail-amer.sun.com>; Wed, 20 Jun 2007 08:11:15 -0600 (MDT) Date: Wed, 20 Jun 2007 08:11:12 -0600 From: Chris Horne Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <20070620075323.GA940478@eng.sun.com> Sender: Chris.Horne@Sun.COM To: Edward Pilatowicz Cc: James Carlson , Tzongyu Paul Lee , Freeman.Liu@Sun.COM, psarc-ext@Sun.COM Message-id: <46793580.9070200@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> <46772898.9020906@Sun.COM> <467788A6.4080908@Sun.COM> <18039.46426.845349.920152@gargle.gargle.HOWL> <4678A430.60006@sun.com> <20070620075323.GA940478@eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Content-Length: 4846 Hi Ed > but in your example below, are you delivering firmware in these > misc modules? or are these misc modules essentially modular > plugins for the scsi_vhci driver? (i thought they were the > latter.) In the example I gave they are plugins, but putting modules that driver xxx is going to ddi_modopen(9F) in a misc/xxx directory helps scope the namespace in both cases (i.e. I think the advise applies to both situations). It also makes sense for these modules to be below "misc" because they use "misc" modlinkage(9s). In addition to the man pages in the original case , this case should also introduce a new modlmisc(9s) peer of modldrv(9s) and modlstrmod(9s) (I missed that in the original case). What's missing is an registry of driver names. We have some registry links available in the bottom of the left hand column of , but there is nothing for driver names (or kernel-module names). (NOTE: this could be initially populated by extracting information from collected customer explorer data). -Chris > this arc case was proposing that the promotion of ddi_modopen() > and friends was for the specific purpose of loading hardware > firmware modules, but there would be no reason that driver > writers wouldn't be able to use these interfaces for modularization > purposes as well, in which case it seems that the documentation > for these interfaces should provide some module naming advice > for both scenarios. > > ed > > On Tue, Jun 19, 2007 at 09:51:12PM -0600, Chris Horne wrote: > >>The reason I did not push naming in the original case >>was because it is easy to get wrong, esp if you don't >>have much use experience. We have some more >>experience now. >> >>For driver use, my recommendation is to fix >> >>6504975 ddi_modopen should allow open in subdirectory >> >>and tell people to deliver into a directory in misc that has the same >>name as the driver. This is what we plan to do as part of >>opensource for mpxio/scsi_vhci. >> >>-Chris >> >># modinfo | grep scsi_vhci >>22 13db490 1a0e8 189 1 scsi_vhci (SCSI VHCI Driver 1.65) >>24 13f5378 1318 - 1 scsi_vhci_f_asym_sun (f_asym_sun 1.28) >>25 13f65c0 34d8 - 1 scsi_vhci_f_asym_lsi (f_asym_lsi 1.28) >>26 13f9860 2630 - 1 scsi_vhci_f_asym_emc (f_asym_emc 1.28) >>27 13fbda8 3f8 - 1 scsi_vhci_f_sym_emc (f_sym_emc 1.3) >>28 13fc0d0 588 - 1 scsi_vhci_f_sym (f_sym 1.28) >>29 13fc510 3148 - 1 scsi_vhci_f_tpgs (f_tpgs 1.28) >># ls -R /kernel/misc/scsi_vhci >>/kernel/misc/scsi_vhci: >>sparcv9 >> >>/kernel/misc/scsi_vhci/sparcv9: >>scsi_vhci_f_asym_emc scsi_vhci_f_asym_sun scsi_vhci_f_sym_emc >>scsi_vhci_f_asym_lsi scsi_vhci_f_sym scsi_vhci_f_tpgs >># find /kernel/drv -name scsi_vhci -print >>/kernel/drv/sparcv9/scsi_vhci >> >> >> >>>Tzongyu Paul Lee writes: >>> >>> >>>>I would suggest that you take some leadership to avoid potential name >>>>space pollution >>>>that is hard to undo later. >>>>The suggestion of using driver name as prefix with special _extension is >>>>quite reasonable. >>>>I like the idea. >>>>We are counting on the disambiguating power of driver name, and that's a >>>>good start. >>>>You can recommend the use of of version/date/descriptive word to driver >>>>writers to manage >>>>their own name space as they see fit. >>>> >>> >>>I would not suggest baking version numbers or (worse) dates into path >>>names unless there's a _really_ good reason to do so. Merely >>>disambiguating modules is not a "good reason." (On the other hand, if >>>we had a magical kernel that could deal with multiple versions of the >>>same module on the system at the same time, then that'd be a good >>>reason.) >>> >>>The original 2005/050 case had a proposal for the naming scheme and, >>>though I asked the submitter of this case about it, I'm really not >>>clear on why this wasn't just brought forward: >>> >>> [_]_[.] >>> >>> For legacy Sun-developed plug-in 'misc' modules the stock-symbol is >>> optional, new Sun-developed modules and third party modules should >>> specify their stock-symbol (SUNW, etc) to avoid name conflicts. If >>> there is only one consumer then may be the consuming >>> (svm's meta disk driver (md(7D) would use "md"), >>> otherwise a more generic name should be used to express purpose. >>> The field describes what variation of an interface is >>> implemented by the plug-in (the legacy "md_mirror" module >>> implements mirroring below the "md" driver). The field is >>> optional, it might be used if programmer decides to implement >>> by-mod-name versioning. >>> >>>(Personally, I'd lose the "" goop here, as it only adds to >>>the potential for disaster, but if it's only a recommendation, I'm >>>slightly less concerned.) >>> >>> From sommerfeld@sun.com Wed Jun 20 12:12:36 2007 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 l5KJCZ9b026579 for ; Wed, 20 Jun 2007 12:12:36 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5KJAsHd006305; Wed, 20 Jun 2007 20:10: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 <0JJY00A177Y6HA00@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Jun 2007 12:10:54 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJY007LF7Y59B40@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Jun 2007 12:10:53 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5KJAmTm018271; Wed, 20 Jun 2007 15:10:48 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5KJAm1K009723; Wed, 20 Jun 2007 15:10:48 -0400 (EDT) Date: Wed, 20 Jun 2007 15:10:46 -0400 From: Bill Sommerfeld Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <20070620075323.GA940478@eng.sun.com> To: Edward Pilatowicz Cc: Chris Horne , psarc-ext@sun.com, Tzongyu Paul Lee , Freeman.Liu@sun.com, James Carlson Message-id: <1182366646.9166.34.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> <46772898.9020906@Sun.COM> <467788A6.4080908@Sun.COM> <18039.46426.845349.920152@gargle.gargle.HOWL> <4678A430.60006@sun.com> <20070620075323.GA940478@eng.sun.com> Status: RO Content-Length: 910 On Wed, 2007-06-20 at 00:53 -0700, Edward Pilatowicz wrote: > but in your example below, are you delivering firmware in these > misc modules? or are these misc modules essentially modular > plugins for the scsi_vhci driver? (i thought they were the > latter.) > > this arc case was proposing that the promotion of ddi_modopen() > and friends was for the specific purpose of loading hardware > firmware modules, but there would be no reason that driver > writers wouldn't be able to use these interfaces for modularization > purposes as well, in which case it seems that the documentation > for these interfaces should provide some module naming advice > for both scenarios. indeed. i'd be happer if these two aspects of the case were disentangled. ddi_modopen() has general utility broader than its use to get at firmware images encapsulated in a kernel module, and would promote its stability as-is. From edward.pilatowicz@sun.com Thu Jun 21 01:19:02 2007 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 l5L8J2X5023637 for ; Thu, 21 Jun 2007 01:19:02 -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 l5L8HMqv003099 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 21 Jun 2007 01:17:23 -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 <0JJZ00L038CY6000@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 21 Jun 2007 01:17:22 -0700 (PDT) Received: from engmail4sca.SFBay.Sun.COM ([129.145.155.74]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJZ007T28CY17E0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 21 Jun 2007 01:17:22 -0700 (PDT) Received: from mcescher.eng.sun.com (mcescher.SFBay.Sun.COM [129.146.224.55]) by engmail4sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5L8HKmx006594; Thu, 21 Jun 2007 01:17:20 -0700 (PDT) Received: from mcescher.eng.sun.com (localhost [127.0.0.1]) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5L8HKgM956312; Thu, 21 Jun 2007 01:17:20 -0700 (PDT) Received: (from edp@localhost) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1/Submit) id l5L8HKom956311; Thu, 21 Jun 2007 01:17:20 -0700 (PDT) Date: Thu, 21 Jun 2007 01:17:16 -0700 From: Edward Pilatowicz Subject: Re: 2007/355 ddi_modopen Stability Promotion In-reply-to: <46793580.9070200@sun.com> To: Chris Horne Cc: James Carlson , Tzongyu Paul Lee , Freeman.Liu@sun.com, psarc-ext@sun.com Message-id: <20070621081716.GC955655@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <18034.53221.712594.998659@gargle.gargle.HOWL> <20070618103616.GA910663@eng.sun.com> <46772898.9020906@Sun.COM> <467788A6.4080908@Sun.COM> <18039.46426.845349.920152@gargle.gargle.HOWL> <4678A430.60006@sun.com> <20070620075323.GA940478@eng.sun.com> <46793580.9070200@sun.com> X-Authentication-warning: mcescher.eng.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 5542 i'm fine with putting both firmware and plugin modules in "misc". my main concern is that the documentation provide guidance on this so it's not a free for all. if those recommendations include the use of the "misc" directory, then i agree that a modlmisc(9s) man page should be delivered as well. lastly, while i think a driver registery is a great idea, that's a seperate issue for another case. ed On Wed, Jun 20, 2007 at 08:11:12AM -0600, Chris Horne wrote: > Hi Ed > > > but in your example below, are you delivering firmware in these > > misc modules? or are these misc modules essentially modular > > plugins for the scsi_vhci driver? (i thought they were the > > latter.) > > In the example I gave they are plugins, but putting modules > that driver xxx is going to ddi_modopen(9F) in a misc/xxx directory > helps scope the namespace in both cases (i.e. I think the advise > applies to both situations). It also makes sense for these > modules to be below "misc" because they use "misc" modlinkage(9s). > > In addition to the man pages in the original case > , this case should also introduce a > new modlmisc(9s) peer of modldrv(9s) and modlstrmod(9s) > (I missed that in the original case). > > What's missing is an registry of driver names. We have some > registry links available in the bottom of the left hand column > of , but there is nothing for driver names > (or kernel-module names). (NOTE: this could be initially > populated by extracting information from collected customer > explorer data). > > -Chris > > > this arc case was proposing that the promotion of ddi_modopen() > > and friends was for the specific purpose of loading hardware > > firmware modules, but there would be no reason that driver > > writers wouldn't be able to use these interfaces for modularization > > purposes as well, in which case it seems that the documentation > > for these interfaces should provide some module naming advice > > for both scenarios. > > > > ed > > > > On Tue, Jun 19, 2007 at 09:51:12PM -0600, Chris Horne wrote: > > > >>The reason I did not push naming in the original case > >>was because it is easy to get wrong, esp if you don't > >>have much use experience. We have some more > >>experience now. > >> > >>For driver use, my recommendation is to fix > >> > >>6504975 ddi_modopen should allow open in subdirectory > >> > >>and tell people to deliver into a directory in misc that has the same > >>name as the driver. This is what we plan to do as part of > >>opensource for mpxio/scsi_vhci. > >> > >>-Chris > >> > >># modinfo | grep scsi_vhci > >>22 13db490 1a0e8 189 1 scsi_vhci (SCSI VHCI Driver 1.65) > >>24 13f5378 1318 - 1 scsi_vhci_f_asym_sun (f_asym_sun 1.28) > >>25 13f65c0 34d8 - 1 scsi_vhci_f_asym_lsi (f_asym_lsi 1.28) > >>26 13f9860 2630 - 1 scsi_vhci_f_asym_emc (f_asym_emc 1.28) > >>27 13fbda8 3f8 - 1 scsi_vhci_f_sym_emc (f_sym_emc 1.3) > >>28 13fc0d0 588 - 1 scsi_vhci_f_sym (f_sym 1.28) > >>29 13fc510 3148 - 1 scsi_vhci_f_tpgs (f_tpgs 1.28) > >># ls -R /kernel/misc/scsi_vhci > >>/kernel/misc/scsi_vhci: > >>sparcv9 > >> > >>/kernel/misc/scsi_vhci/sparcv9: > >>scsi_vhci_f_asym_emc scsi_vhci_f_asym_sun scsi_vhci_f_sym_emc > >>scsi_vhci_f_asym_lsi scsi_vhci_f_sym scsi_vhci_f_tpgs > >># find /kernel/drv -name scsi_vhci -print > >>/kernel/drv/sparcv9/scsi_vhci > >> > >> > >> > >>>Tzongyu Paul Lee writes: > >>> > >>> > >>>>I would suggest that you take some leadership to avoid potential name > >>>>space pollution > >>>>that is hard to undo later. > >>>>The suggestion of using driver name as prefix with special _extension is > >>>>quite reasonable. > >>>>I like the idea. > >>>>We are counting on the disambiguating power of driver name, and that's a > >>>>good start. > >>>>You can recommend the use of of version/date/descriptive word to driver > >>>>writers to manage > >>>>their own name space as they see fit. > >>>> > >>> > >>>I would not suggest baking version numbers or (worse) dates into path > >>>names unless there's a _really_ good reason to do so. Merely > >>>disambiguating modules is not a "good reason." (On the other hand, if > >>>we had a magical kernel that could deal with multiple versions of the > >>>same module on the system at the same time, then that'd be a good > >>>reason.) > >>> > >>>The original 2005/050 case had a proposal for the naming scheme and, > >>>though I asked the submitter of this case about it, I'm really not > >>>clear on why this wasn't just brought forward: > >>> > >>> [_]_[.] > >>> > >>> For legacy Sun-developed plug-in 'misc' modules the stock-symbol is > >>> optional, new Sun-developed modules and third party modules should > >>> specify their stock-symbol (SUNW, etc) to avoid name conflicts. If > >>> there is only one consumer then may be the consuming > >>> (svm's meta disk driver (md(7D) would use "md"), > >>> otherwise a more generic name should be used to express purpose. > >>> The field describes what variation of an interface is > >>> implemented by the plug-in (the legacy "md_mirror" module > >>> implements mirroring below the "md" driver). The field is > >>> optional, it might be used if programmer decides to implement > >>> by-mod-name versioning. > >>> > >>>(Personally, I'd lose the "" goop here, as it only adds to > >>>the potential for disaster, but if it's only a recommendation, I'm > >>>slightly less concerned.) > >>> > >>> From carlsonj@phorcys.east.sun.com Thu Jun 21 07:19:32 2007 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 l5LEJVEV000607 for ; Thu, 21 Jun 2007 07:19:31 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5LEHgvm016836; Thu, 21 Jun 2007 15:17:50 +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 <0JJZ0090EP1PBA00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Jun 2007 07:17:49 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJZ002WUP1N1W80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Jun 2007 07:17:48 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5LEHlrN008985; Thu, 21 Jun 2007 10:17:47 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5LEHlR2008982; Thu, 21 Jun 2007 10:17:47 -0400 (EDT) Date: Thu, 21 Jun 2007 10:17:47 -0400 From: James Carlson Subject: 2007/355 ddi_modopen Stability Promotion To: psarc-ext@sun.com Cc: Freeman.Liu@sun.com Message-id: <18042.34955.553566.6411@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 694 This fast-track was approved during ARC business at yesterday's meeting. I've placed an updated version of the specification in the case directory (including the required modlmisc(9S) reference, but not including subdirectories or a registry), and I encourage those who are interested in refining the advice to users (for man pages or the wdd document, on topics of usage or module naming practices) to work with the submitter off-line to get that advice hammered out. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677