From cth@sac.sfbay.sun.com Fri Jun 13 14:31:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DLVibW008020 for ; Fri, 13 Jun 2008 14:31:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DLVdc6010783; Fri, 13 Jun 2008 22:31:43 +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 <0K2F00A037SSPK00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 14:31:40 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F006Y67SS7840@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 14:31:40 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DLVexi035070; Fri, 13 Jun 2008 14:31:40 -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 m5DLVcTp008014; Fri, 13 Jun 2008 14:31:38 -0700 (PDT) Received: (from cth@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m5DLVc3r008010; Fri, 13 Jun 2008 14:31:38 -0700 (PDT) Date: Fri, 13 Jun 2008 14:31:38 -0700 (PDT) From: Christopher Horne Subject: mod_modname(9F) [PSARC/2008/380 FastTrack timeout 06/25/2008] To: PSARC-ext@sun.com Message-id: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5350 I am sponsoring the following fasttrack for myself, requesting patch binding and a timeout of 06/28/2007. -Chris Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: mod_modname(9F) 1.2. Name of Document Author/Supplier: Author: Chris Horne 1.3 Date of This Document: 13 June, 2008 4. Technical Description 4.1 Problem For maximum flexibility, it is best if a driver does not have compiled-in knowledge of its own name. Existing ddi_driver_name(9F) and ddi_driver_major(9F) interfaces facilitate this type of independence when a 'dev_info_t' is available (attach(9E) do detach(9E) driver scope). Some of the interfaces that drivers use during _init(9E), like kmem_cache_create(9F) and kstat_create(9F), need to know the driver name. There is currently no public interface for them to use to determine driver name during _init. 4.2 Proposal This fasttrack requests promotion of mod_modname(9F) - an interface that can be used to determine the name of the module/driver during _init(9E) time using modlinkage(9S) information. The ddi_modname() interface was added in s10_59 as part of CR5033382 "sd driver should not depend on hard-coded driver name". In addition, the definition for DDI_MAJOR_T_NONE is missing. This define is mentioned in the ddi_driver_major(9F), ddi_prop_create(9f), and ddi_prop_update(9F) man pages. The following define will be added to #define DDI_MAJOR_T_NONE ((major_t)-1) 4.4 Interface Table ------------------------------------------------------------------------ Interface Level Comments ------------------------------------------------------------------------ mod_modname(9F) Commited Promotion: Given a modlinkage(9S), return the name of the module/driver. DDI_MAJOR_T_NONE Commited Provide definition. 4.5 References 4.6 Man page changes See below. 6. Resources and Schedule 6.4 Steering Committee requested information 6.4.1 Consolidation C-team Name: ON 6.5 ARC review type: FastTrack A.1 Proposed mod_modname(9F)/mod_install(9F) changes: Kernel Functions for Drivers mod_install(9F) NAME + mod_install, mod_remove, mod_info, mod_modname - + add, remove or query a loadable module SYNOPSIS #include int mod_install(struct modlinkage *modlinkage); int mod_remove(struct modlinkage *modlinkage); int mod_info(struct modlinkage *modlinkage, struct modinfo *modinfo); + char *mod_modname(struct modlinkage *modlinkage); INTERFACE LEVEL Solaris DDI specific (Solaris DDI). PARAMETERS modlinkage Pointer to the loadable module's modlinkage structure which describes what type(s) of module elements are included in this loadable module. modinfo Pointer to the modinfo structure passed to _info(9E). DESCRIPTION mod_install() must be called from a module's _init(9E) rou- tine. mod_remove() must be called from a module's _fini(9E) rou- tine. mod_info() must be called from a module's _info(9E) routine. + mod_modname() can be called from any module routine. When _init(9E) is executing, its call to mod_install() enables other threads to call attach(9E) even prior to mod_install() returning and _init(9E) completion. From a programming standpoint this means that all _init(9E) ini- tialization must occur prior to _init(9E) calling mod_install(). If mod_install() fails (non-zero return value), any initialization must be undone. When _fini(9E) is executing, another thread may call attach(9E) prior to _fini(9E) calling mod_remove(). If this occurs, the mod_remove() fails (non-zero return). From a programming standpoint, this means that _init(9E) initiliza- tions should only be undone after a successful return from mod_remove(). + To query the name of a module, use mod_modname(). If the module + is a driver, the module name is the same as the driver name. + This function can be used to avoid compiled-in knowledge of the + module name, and is of particular use when _init(9E) needs to + call a function like kstat_create(9F). RETURN VALUES mod_install() and mod_remove() return 0 upon success and non-zero on failure. mod_info() returns a non-zero value on success and 0 upon failure. + mod_modname() returns the name of the module. The returned + name remains valid as long as the module remains loaded. EXAMPLES See _init(9E) for an example that uses these functions. SEE ALSO _fini(9E), _info(9E), _init(9E), modldrv(9S), modlinkage(9S), modlstrmod(9S) 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 13 15:12:28 2008 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 m5DMCRmg012702 for ; Fri, 13 Jun 2008 15:12:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DMCRNE019975 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Fri, 13 Jun 2008 16:12:27 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F0012B9OR4F00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 13 Jun 2008 16:12:27 -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 <0K2F008E69OPUN90@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 13 Jun 2008 16:12:25 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DMCOFb019487; Fri, 13 Jun 2008 18:12:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5DMCOA3019484; Fri, 13 Jun 2008 18:12:24 -0400 (EDT) Date: Fri, 13 Jun 2008 18:12:24 -0400 From: James Carlson Subject: Re: mod_modname(9F) [PSARC/2008/380 FastTrack timeout 06/25/2008] In-reply-to: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> To: Christopher Horne Cc: PSARC-ext@sun.com Message-id: <18514.61640.496069.589057@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.4.1.325704 References: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> Status: RO Content-Length: 1195 Christopher Horne writes: > For maximum flexibility, it is best if a driver does not have > compiled-in knowledge of its own name. Existing What does "maximum flexibility" mean here? Under what normal conditions would a driver need to be installed under different names ... ? I guess I have nothing against the interface -- it seems obvious enough in design -- but the usage seems pretty obscure. > information. The ddi_modname() interface was added in s10_59 > as part of CR5033382 "sd driver should not depend on hard-coded > driver name". That shows a debug example, where (I'd guess) someone could just as easily recompile with a new name. Are there other cases where renaming on the fly makes sense? > + char *mod_modname(struct modlinkage *modlinkage); Code review nit: I suggest 'const char *' as a return value here (and perhaps a const argument as well). The string this returns shouldn't normally be modified by a user. (And if it is ...) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Fri Jun 13 15:46:37 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DMkann016138 for ; Fri, 13 Jun 2008 15:46:36 -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 m5DMkT73001334 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Jun 2008 06:46:35 +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 <0K2F00E01B9KJ300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 15:46:32 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F006A7B9K7290@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 15:46:32 -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 m5DMkVOQ014403 for ; Fri, 13 Jun 2008 15:46:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2F00D01AXUVJ00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 15:46:31 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2F00HSWB9GVA00@fe-sfbay-10.sun.com>; Fri, 13 Jun 2008 15:46:28 -0700 (PDT) Date: Fri, 13 Jun 2008 15:45:22 -0700 From: "Garrett D'Amore" Subject: Re: mod_modname(9F) [PSARC/2008/380 FastTrack timeout 06/25/2008] In-reply-to: <18514.61640.496069.589057@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Christopher Horne , PSARC-ext@sun.com Message-id: <4852F882.1060300@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> <18514.61640.496069.589057@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1805 James Carlson wrote: > Christopher Horne writes: > >> For maximum flexibility, it is best if a driver does not have >> compiled-in knowledge of its own name. Existing >> > > What does "maximum flexibility" mean here? Under what normal > conditions would a driver need to be installed under different names > ... ? > > I guess I have nothing against the interface -- it seems obvious > enough in design -- but the usage seems pretty obscure. > The only thing I can think of is in some weird situation, where, for example, a driver or module is having something done on behalf of it in some framework somewhere. For example, something like xxx_framework_initops(struct modlinkage *). It does seem of pretty limited utility, though. > >> information. The ddi_modname() interface was added in s10_59 >> as part of CR5033382 "sd driver should not depend on hard-coded >> driver name". >> > > That shows a debug example, where (I'd guess) someone could just as > easily recompile with a new name. Are there other cases where > renaming on the fly makes sense? > > >> + char *mod_modname(struct modlinkage *modlinkage); >> > > Code review nit: I suggest 'const char *' as a return value here (and > perhaps a const argument as well). The string this returns shouldn't > normally be modified by a user. (And if it is ...) > YES PLEASE! Its really quite annoying when folks don't use const char * when they should. Its more important, IMO, that the functions take const pointers than return them. (The fact that large portions of our DDI are not const-ipated, makes it really hard to use const char * elsewhere where we should. Fixing this across the board may actually gain some performance improvements due to better optimization.) -- Garrett From Chris.Horne@sun.com Sat Jun 14 08:41:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5EFfcTM007588 for ; Sat, 14 Jun 2008 08:41:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5EFfYlN013675 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Jun 2008 16:41:37 +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 <0K2G00I01M9BOX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 14 Jun 2008 08:41:35 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2G00AZPM9A7U50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 14 Jun 2008 08:41:34 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5EFfYld028022 for ; Sat, 14 Jun 2008 15:41:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2G00E01M8X3M00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 14 Jun 2008 09:41:34 -0600 (MDT) Received: from sun.com ([129.150.32.170]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2G00GO6M8ZG160@mail-amer.sun.com>; Sat, 14 Jun 2008 09:41:34 -0600 (MDT) Date: Sat, 14 Jun 2008 09:41:23 -0600 From: Chris Horne Subject: Re: mod_modname(9F) [PSARC/2008/380 FastTrack timeout 06/25/2008] In-reply-to: <4852F882.1060300@sun.com> Sender: Chris.Horne@sun.com To: "Garrett D'Amore" , James Carlson Cc: Christopher Horne , PSARC-ext@sun.com Message-id: <4853E6A3.8050802@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.4.1.325704 References: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> <18514.61640.496069.589057@gargle.gargle.HOWL> <4852F882.1060300@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Content-Length: 4100 Hi James, Garrett > >> >>> >>> For maximum flexibility, it is best if a driver does not have >>> compiled-in knowledge of its own name. Existing >>What does "maximum flexibility" mean here? Under what normal >>conditions would a driver need to be installed under different names >>... ? >>I guess I have nothing against the interface -- it seems obvious >>enough in design -- but the usage seems pretty obscure. > > The only thing I can think of is in some weird situation, where, for > example, a driver or module is having something done on behalf of it in > some framework somewhere. > > For example, something like xxx_framework_initops(struct modlinkage *). > It does seem of pretty limited utility, though. > >>> information. The ddi_modname() interface was added in s10_59 >>> as part of CR5033382 "sd driver should not depend on hard-coded >>> driver name". >> >>That shows a debug example, where (I'd guess) someone could just as >>easily recompile with a new name. Are there other cases where >>renaming on the fly makes sense? For a developer, I think that having a driver cp(1)-clonable is easier than requiring cloning of the driver source and changing makefiles. Also, if a developer chooses to clone the driver source, they will still need to avoid kstat/kmem_cache-like namespace collision. To do this, the driver developer must find the origin of all global namespace collisions. Once identified, the developer needs to modify fixed 'driver_name' strings. When development is complete, and the cloned source branch gets folded back into the original driver code base, the developer needs to remember to change these strings back. This is awkward. With ddi_modname() the developer can identify the conflicts once, switch to ddi_modname() use, and never have to deal with the issue again. For initialization off _init(9E), there is currently no way to determine the driver/module name at run time: that is the problem that ddi_modname() solves - for both source-clone development and to enable future cp-clonable development. After a driver is cp-clonable, development can occur in-place (without setting up a cloned source branch). With a Solaris goal of 'supporting the developer', I believe that enabling a driver to be cp-clonable makes the development of subsequent bug fixes and enhancements easier - especially for drivers involved in mounting the root device (where you don't want early use of development bits to cause the machine to fail to boot). There is also a weaker use-case for drivers, like sgen, where different bindings can be established at different times for different purposes - where a single 'rem_drv', when uninstalling software, will remove all bindings. For example if one package establishes a self-identifying sgen binding for a scanner, and another establishes a self-identifying binding for a media changer - when a customer removes the scanner software he also ends up deleting the alias for the media changer. The proper way of doing this would be to add and remove aliases via "update_drv -a/-d -i", but there is existing practice and third party products that say "run 'rem_drv sgen'". Making a driver cp-clonable could provide a workaround that accommodates existing practice >> >>>+ char *mod_modname(struct modlinkage *modlinkage); >>> >> >>Code review nit: I suggest 'const char *' as a return value here (and >>perhaps a const argument as well). The string this returns shouldn't >>normally be modified by a user. (And if it is ...) >> > > YES PLEASE! Its really quite annoying when folks don't use const char * > when they should. Its more important, IMO, that the functions take > const pointers than return them. (The fact that large portions of our > DDI are not const-ipated, makes it really hard to use const char * > elsewhere where we should. Fixing this across the board may actually > gain some performance improvements due to better optimization.) OK - I will ensure that the man page changes and implementation use "const char *". -Chris From carlsonj@phorcys.east.sun.com Sat Jun 14 11:43:23 2008 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 m5EIhNXj010161 for ; Sat, 14 Jun 2008 11:43:23 -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 m5EIhL65026578; Sat, 14 Jun 2008 12:43:22 -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 <0K2G00M01UO99F00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 14 Jun 2008 11:43:21 -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 <0K2G007M7UO8ZX90@nwk-avmta-1.sfbay.Sun.COM>; Sat, 14 Jun 2008 11:43:20 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5EIhJQi020805; Sat, 14 Jun 2008 14:43:19 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5EIhJfj020802; Sat, 14 Jun 2008 14:43:19 -0400 (EDT) Date: Sat, 14 Jun 2008 14:43:19 -0400 From: James Carlson Subject: Re: mod_modname(9F) [PSARC/2008/380 FastTrack timeout 06/25/2008] In-reply-to: <4853E6A3.8050802@sun.com> To: Chris Horne Cc: "Garrett D'Amore" , Christopher Horne , PSARC-ext@sun.com Message-id: <18516.4423.419840.497261@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.4.1.325704 References: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> <18514.61640.496069.589057@gargle.gargle.HOWL> <4852F882.1060300@sun.com> <4853E6A3.8050802@sun.com> Status: RO Content-Length: 1822 Chris Horne writes: > With a Solaris goal of 'supporting the developer', I believe that > enabling a driver to be cp-clonable makes the development of subsequent > bug fixes and enhancements easier - especially for drivers involved in > mounting the root device (where you don't want early use of development > bits to cause the machine to fail to boot). That's the only one of these scenarios that makes sense to me. OK ... as I said before, I was mostly curious what the motivation was, as I've worked on all sorts of drivers, and it's hard for me to see how or why I'd ever really want to clone one by copying the binary. :-/ > software he also ends up deleting the alias for the media changer. The > proper way of doing this would be to add and remove aliases via > "update_drv -a/-d -i", but there is existing practice and third party > products that say "run 'rem_drv sgen'". Making a driver cp-clonable > could provide a workaround that accommodates existing practice yikes. I hope that's never used as anything other than as a work-around. I can see this getting confusing over time. Especially if 'cp' is really what's used -- after patching the system, those cp-based clones will be using old slightly-different code, but the originals will be using new code. The conflicts could be spectacular. There are instances of drivers using name-based information to ensure that there's only one instance of a control node or user-space daemon or the like. Could the feature perhaps need a warning label? ("For driver developers only; administrators, please don't try this at home.") -- James Carlson, Solaris Networking Sun Microsystems / 35 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 Sat Jun 14 13:08:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5EK8KB7011503 for ; Sat, 14 Jun 2008 13:08:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5EK83LB024297 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Jun 2008 21:08:19 +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 <0K2G00901YLTZY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 14 Jun 2008 13:08:17 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2G008SZYLTB910@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 14 Jun 2008 13:08:17 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5EK8HSU002000 for ; Sat, 14 Jun 2008 20:08:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2G00K01YJ9KR00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 14 Jun 2008 14:08:17 -0600 (MDT) Received: from sun.com ([129.150.32.170]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2G00GTMYLSG180@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 14 Jun 2008 14:08:16 -0600 (MDT) Date: Sat, 14 Jun 2008 14:08:16 -0600 From: Chris Horne Subject: Re: mod_modname(9F) [PSARC/2008/380 FastTrack timeout 06/25/2008] In-reply-to: <18516.4423.419840.497261@gargle.gargle.HOWL> Sender: Chris.Horne@sun.com To: James Carlson Cc: PSARC-ext@sun.com Message-id: <48542530.5060502@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.4.1.325704 References: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> <18514.61640.496069.589057@gargle.gargle.HOWL> <4852F882.1060300@sun.com> <4853E6A3.8050802@sun.com> <18516.4423.419840.497261@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Content-Length: 1460 Hi James >>software he also ends up deleting the alias for the media changer. The >>proper way of doing this would be to add and remove aliases via >>"update_drv -a/-d -i", but there is existing practice and third party >>products that say "run 'rem_drv sgen'". Making a driver cp-clonable >>could provide a workaround that accommodates existing practice > > yikes. > > I hope that's never used as anything other than as a work-around. I > can see this getting confusing over time. Especially if 'cp' is > really what's used -- after patching the system, those cp-based clones > will be using old slightly-different code, but the originals will be > using new code. The conflicts could be spectacular. > > There are instances of drivers using name-based information to ensure > that there's only one instance of a control node or user-space daemon > or the like. > > Could the feature perhaps need a warning label? ("For driver > developers only; administrators, please don't try this at home.") I said upfront that this use case was weak: I would not propose this for anything but a last-resort work-around. There are multiple pages of google hits on "rem_drv sgen", which is an inappropriate command for a multi-application driver like sgen - so the need for a work-around could arise. Unfortunately, there are open issues with update_drv to consider too. http://monaco.sfbay.sun.com/detail.jsf?cr=4854243,6198348,6464765,6612207,6674099 -Chris From chris.horne@sun.com Wed Jun 25 10:16:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PHGg4C007978 for ; Wed, 25 Jun 2008 10:16:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PHGeeL025210 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 18:16:41 +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 <0K31007073ZRG000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 11:16:39 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31004MY3ZQ1420@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 11:16:39 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PHGcJ6019296 for ; Wed, 25 Jun 2008 17:16:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3100G012PD5400@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 25 Jun 2008 11:16:38 -0600 (MDT) Received: from [172.20.25.50] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K31004O33ZE3010@mail-amer.sun.com>; Wed, 25 Jun 2008 11:16:26 -0600 (MDT) Date: Wed, 25 Jun 2008 11:16:23 -0600 From: Chris Horne Subject: Re: mod_modname(9F) [PSARC/2008/380 FastTrack timeout 06/25/2008] In-reply-to: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> Sender: chris.horne@sun.com To: Christopher Horne Cc: PSARC-ext@sun.com Message-id: <48627D67.8070008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806132131.m5DLVc3r008010@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 46 This case as approved at PSARC today. -Chris