From Artem.Kachitchkin@sun.com Thu Jan 29 10:09:57 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TI9vbo025705 for ; Thu, 29 Jan 2009 10:09:57 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0TI9qlU024471 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Jan 2009 10:09:57 -0800 (PST) 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 <0KE800H05VSLN200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Thu, 29 Jan 2009 11:09:57 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE800ARJVSKM990@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Thu, 29 Jan 2009 11:09:56 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0TI9uce003435 for ; Thu, 29 Jan 2009 10:09:56 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE800301VJHLL00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 29 Jan 2009 10:09:56 -0800 (PST) Received: from [129.150.20.24] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE800GJBVSG2P60@fe-sfbay-09.sun.com>; Thu, 29 Jan 2009 10:09:53 -0800 (PST) Date: Thu, 29 Jan 2009 10:09:28 -0800 From: Artem Kachitchkine Subject: PSARC/2009/058 physical eject button Sender: Artem.Kachitchkin@sun.com To: PSARC-ext@sun.com Message-id: <4981F0D8.2010400@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 User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 5427 I'm sponsoring this fasttrack for myself. Minor release binding is requested. The timer is set for 02/06/2009. -Artem Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: physical eject button 1.2. Name of Document Author/Supplier: Author: Artem Kachitchkine 1.3 Date of This Document: 29 January, 2009 4. Technical Description 4.1. Summary For years, operating systems have allowed users to unmount and eject removable media by pressing the physical eject button located on the drive's front panel. In fact, to a certain class of users, that's the only way they know. We propose to add this feature to Solaris such that pressing the button is functionally equivalent to using eject(1) or mouse-clicking on the corresponding GUI primitive. 4.2. Details device | | GET EVENT STATUS NOTIFICATION v scsi watch | | callback v sd driver | | sysevent v HAL (hald-addon-storage) | | DBus signal / \ / \ GNOME rmvolmgr 4.2.1. Kernel We propose to use the MMC-3 command GET EVENT STATUS NOTIFICATION that reports, among other information: media presence, tray status, and eject requests from the eject button. The same command is used for media polling in Linux, FreeBSD and Windows (we verified versions 98 and XP). So for target devices, Solaris host will look very similar to the other hosts, which should minimize the chances of incompatibilities due to undertested firmware, etc. This command will be added to the kernel scsi watch facility, used by sd(7D) driver to monitor media presence and implement dkio(7I) DKIOCSTATE ioctl. Scsi watch periodically (every 3 seconds) sends either a TEST UNIT READY or a zero-length WRITE to the device, and based on returned status, sd determines if media is present. We propose that scsi watch use GET EVENT STATUS NOTIFICATION on target driver's request. Sd will prefer this command when: controller type is CDROM, and device is MMC compliant, and positively responds to GET EVENT STATUS NOTIFICATION command attempted during driver attach. Otherwise sd will use the current mechanism. We will provide a new SCSA function, scsi_mmc_watch_request_submit(), similar to the existing scsi_watch_request_submit(). By using GET EVENT STATUS NOTIFICATION, sd can provide the very same DKIOCSTATE functionality transparently to applications. In addition, it can detect physical eject button presses and notify applications. We propose that sd emit a sysevent when it detects an eject request: Class: EC_dev_status - existing, introduced in PSARC/2006/373 Subclass: ESC_dev_eject_request - new, part of this case Attribute: phys_path - device path Even with careful implementation and testing, a small chance remains of some MMC devices misbehaving when switched to the new polling command. To facilitate diagnostics in the field, we propose a new sd.conf boolean property 'mmc-gesn-polling': when set to false, sd would use the old polling method for MMC devices. 4.2.2. Userland The sysevent will be consumed by the hal(5) daemon, specifically its storage add-on, responsible for monitoring media state and informing applications via DBus. The HAL API already defines the "EjectPressed" device condition, and GNOME volume manager/GVFS layer already support it by initiating Eject() method in response to the condition. This proposal requires no changes to the GNOME code. Solaris also provides rmvolmgr(1M), the "console volume manager", responsible for automounting in absence of the local desktop session. We propose that rmvolmgr support the new feature, but it be disabled by default, i.e. ignore the "EjectPressed" condition. Our reasoning is to reduce the element of surprise in cases involving headless machines, like accidentally pressing eject on a rack-mounted server, and generally Solaris admins are used to the locked CDROM door with media present. We will provide a boolean SMF property 'eject_button' for svc:/system/filesystem/rmvolmgr:default: when set to true, rmvolmgr will respond to the "EjectPressed" condition. 4.3. Interfaces Exported: --------------------------------+---------------+----------------------- scsi_mmc_watch_request_submit | Cons. Private | scsi watch function ESC_dev_eject_request | Committed | sysevent subclass eject_button | Uncommitted | SMF property mmc-gesn-polling | Uncommitted | sd.conf property --------------------------------+---------------+----------------------- Imported: --------------------------------+---------------+----------------------- EC_dev_status | Committed | sysevent class EjectPressed | Volatile | HAL device condition svc:/system/filesystem/rmvolmgr | Uncommitted | SMF service --------------------------------+---------------+----------------------- 4.4. References PSARC/2005/399 Tamarack: Removable Media Enhancements in Solaris PSARC/2006/373 Dynamic LUN Expansion SCSI Multimedia Commands - 3 (MMC-3) http://www.microsoft.com/whdc/device/storage/GESN_Imp.mspx 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Thu Jan 29 10:15:03 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TIF2sq025898 for ; Thu, 29 Jan 2009 10:15:03 -0800 (PST) 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 n0TIDfaH022748 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Jan 2009 02:15:01 +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 <0KE800L0DW10KZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 10:15:00 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE800IVMW0Y0230@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 10:14:59 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0TIEwOf005719 for ; Thu, 29 Jan 2009 18:14:58 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE800K01W041Y00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 18:14:58 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE800LBZW0YZN10@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 18:14:58 +0000 (GMT) Date: Thu, 29 Jan 2009 18:14:58 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4981F0D8.2010400@sun.com> Sender: Darren.Moffat@sun.com To: Artem Kachitchkine Cc: PSARC-ext@sun.com Message-id: <4981F222.2020206@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: <4981F0D8.2010400@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 343 I'm happy except for the overly conservative behaviour with rmvolmgr being different to when gnome is running. I think the default should be the same as when gnome is running but keep the very useful SMF property so that the ultra paranoid can stop the mice that run around their datacentre from stealing their CDs. -- Darren J Moffat From gdamore@sun.com Thu Jan 29 10:39:19 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TIdIUX026332 for ; Thu, 29 Jan 2009 10:39:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0TId2EN005897 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Jan 2009 02:39:17 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE800K0VX5EHC00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:39:14 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE800A53X56LWD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:39:06 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0TId6Gp011877 for ; Thu, 29 Jan 2009 10:39:06 -0800 (PST) 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 <0KE800B01WLP5I00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 10:39:06 -0800 (PST) Received: from [192.168.251.11] ([76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE800LBFX4WKA20@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 10:38:56 -0800 (PST) Date: Thu, 29 Jan 2009 10:38:56 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4981F222.2020206@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4981F7C0.1060508@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: <4981F0D8.2010400@sun.com> <4981F222.2020206@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 537 Darren J Moffat wrote: > I'm happy except for the overly conservative behaviour with rmvolmgr > being different to when gnome is running. I think the default should > be the same as when gnome is running but keep the very useful SMF > property so that the ultra paranoid can stop the mice that run around > their datacentre from stealing their CDs. > +1 on both counts. The property should be put in the .conf file and documented in the man page(s) for sd and probably also rmvolmgr so that admins can find it. -- Garrett From Artem.Kachitchkin@sun.com Thu Jan 29 10:52:36 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TIqZre026545 for ; Thu, 29 Jan 2009 10:52:36 -0800 (PST) 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 n0TIqZln033896 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Jan 2009 11:52:35 -0700 (MST) 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 <0KE800L01XRKRT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:52:32 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE800AZCXRKM7D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:52:32 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0TIqVVb009716 for ; Thu, 29 Jan 2009 10:52:31 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE800A01WXCKU00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 10:52:31 -0800 (PST) Received: from [129.150.20.24] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE8007I6XQX1T90@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 10:52:09 -0800 (PST) Date: Thu, 29 Jan 2009 10:51:44 -0800 From: Artem Kachitchkine Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4981F7C0.1060508@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <4981FAC0.7060102@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: <4981F0D8.2010400@sun.com> <4981F222.2020206@Sun.COM> <4981F7C0.1060508@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 748 Garrett D'Amore wrote: > Darren J Moffat wrote: >> I'm happy except for the overly conservative behaviour with rmvolmgr >> being different to when gnome is running. I think the default should >> be the same as when gnome is running but keep the very useful SMF >> property so that the ultra paranoid can stop the mice that run around >> their datacentre from stealing their CDs. >> > +1 on both counts. The property should be put in the .conf file and > documented in the man page(s) for sd and probably also rmvolmgr so that > admins can find it. The proposed SMF property and the sd property are independent and serve different purposes. Darren was referring to the former. Or was your second sentence unrelated to the first? -Artem From gdamore@sun.com Thu Jan 29 11:09:52 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TJ9pB9027378 for ; Thu, 29 Jan 2009 11:09:51 -0800 (PST) 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 n0TJ9f3m022981 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Jan 2009 03:09:50 +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 <0KE800103YKCXF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:09:48 -0800 (PST) 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 <0KE800HS2YKCZZ90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:09:48 -0800 (PST) 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 n0TJ9mK2012496 for ; Thu, 29 Jan 2009 11:09:48 -0800 (PST) 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 <0KE800401YCWP700@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:09:48 -0800 (PST) Received: from [192.168.251.11] ([76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE800AY0YJZ8C00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:09:35 -0800 (PST) Date: Thu, 29 Jan 2009 11:09:34 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4981FAC0.7060102@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <4981FEEE.5010408@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: <4981F0D8.2010400@sun.com> <4981F222.2020206@Sun.COM> <4981F7C0.1060508@sun.com> <4981FAC0.7060102@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1153 Artem Kachitchkine wrote: > Garrett D'Amore wrote: >> Darren J Moffat wrote: >>> I'm happy except for the overly conservative behaviour with rmvolmgr >>> being different to when gnome is running. I think the default >>> should be the same as when gnome is running but keep the very useful >>> SMF property so that the ultra paranoid can stop the mice that run >>> around their datacentre from stealing their CDs. >>> >> +1 on both counts. The property should be put in the .conf file and >> documented in the man page(s) for sd and probably also rmvolmgr so >> that admins can find it. > > The proposed SMF property and the sd property are independent and > serve different purposes. Darren was referring to the former. Or was > your second sentence unrelated to the first? Doh, I wasn't paying close enough attention. I was referring the SMF property, and hence sd.conf doesn't make much sense. I don't think the sd property (polling behavior) needs to be documented anywhere other than perhaps in the .conf file itself -- since we don't think it will be necessary except in the face of bugs (hardware or otherwise). -- Garrett From Artem.Kachitchkin@sun.com Thu Jan 29 11:31:03 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TJV3cJ028436 for ; Thu, 29 Jan 2009 11:31:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0TJV14w012572 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Jan 2009 11:31:02 -0800 (PST) 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 <0KE80030JZJQ5800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:31:02 -0800 (PST) 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 <0KE800HSAZJPZUA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:31:01 -0800 (PST) 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 n0TJV13c015612 for ; Thu, 29 Jan 2009 11:31:01 -0800 (PST) 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 <0KE800201ZI6FX00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:31:01 -0800 (PST) Received: from [129.146.104.83] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE800AKTZJJ8CB0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 11:30:55 -0800 (PST) Date: Thu, 29 Jan 2009 11:31:52 -0800 From: Artem Kachitchkine Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4981F222.2020206@Sun.COM> Sender: Artem.Kachitchkin@sun.com To: Darren J Moffat , PSARC-ext@sun.com Message-id: <49820428.1050509@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: <4981F0D8.2010400@sun.com> <4981F222.2020206@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 611 On 01/29/09 10:14, Darren J Moffat wrote: > I'm happy except for the overly conservative behaviour with rmvolmgr > being different to when gnome is running. I think the default should > be the same as when gnome is running but keep the very useful SMF > property so that the ultra paranoid can stop the mice that run around > their datacentre from stealing their CDs. Thanks, I was unsure about this one and wanted to hear more opinions. I will let others to contribute over the next few days, and if we have a consensus, I will change rmvolmgr's default behavior to be consistent with GNOME. -Artem From Joerg.Schilling@fokus.fraunhofer.de Fri Jan 30 00:56:08 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0U8u7SN028368 for ; Fri, 30 Jan 2009 00:56:07 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0U8u4il007063; Fri, 30 Jan 2009 00:56:07 -0800 (PST) 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 <0KEA00E0T0THYM00@brm-avmta-1.central.sun.com>; Fri, 30 Jan 2009 01:56:05 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEA00D490THKZ10@brm-avmta-1.central.sun.com>; Fri, 30 Jan 2009 01:56:05 -0700 (MST) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0U8hPMN004441; Fri, 30 Jan 2009 08:56:04 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay42i.sun.com with ESMTP id BT-MMP-60275; Fri, 30 Jan 2009 08:56:04 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-348041; Fri, 30 Jan 2009 08:56:03 +0000 (Z) Received: from iron02.fraunhofer.de ([153.96.1.56] [153.96.1.56]) by relay4i.sun.com with ESMTP id BT-MMP-646856; Fri, 30 Jan 2009 08:56:03 +0000 (Z) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by iron02.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; Fri, 30 Jan 2009 09:56:02 +0100 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id n0U8u2bG021018; Fri, 30 Jan 2009 09:56:02 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 09:56:02 +0100 Date: Fri, 30 Jan 2009 09:56:02 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4981F0D8.2010400@sun.com> To: PSARC-ext@sun.com, Artem.Kachitchkin@sun.com Message-id: <4982c0a2.zazNTx7+UJg7B6HI%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.4/5.0, scanned in 0.629sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4981F0D8.2010400@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 30 Jan 2009 08:56:02.0349 (UTC) FILETIME=[93E2FDD0:01C982B8] Status: RO Content-Length: 1844 Artem Kachitchkine wrote: > I'm sponsoring this fasttrack for myself. Minor release binding is > requested. The timer is set for 02/06/2009. > > -Artem > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > physical eject button > 1.2. Name of Document Author/Supplier: > Author: Artem Kachitchkine > 1.3 Date of This Document: > 29 January, 2009 > 4. Technical Description > 4.1. Summary > > For years, operating systems have allowed users to unmount and > eject removable media by pressing the physical eject button located > on the drive's front panel. In fact, to a certain class of users, > that's the only way they know. We propose to add this feature to > Solaris such that pressing the button is functionally equivalent to > using eject(1) or mouse-clicking on the corresponding GUI primitive. This would change the behavior. Do you plan to alternatively allow to have the eject button blocked as before? Note that people may likke to have the button locked in order to prevent to eject the media by accident. BTW: cdrecord (when going to write to a CD / DVD / BD) loads the medium, then locks the eject button and will not unlock the eject button before the write process to the medium has been completed. Is there a potential problem that could remove the lock from the eject button that has been established by cdrecord and thus make cdrecord less reliable than before? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Artem.Kachitchkin@sun.com Fri Jan 30 09:38:09 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0UHc8iJ013974 for ; Fri, 30 Jan 2009 09:38:08 -0800 (PST) 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 n0UHc7Rf005752 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Jan 2009 17:38:07 GMT 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 <0KEA00K0HOZIHM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 30 Jan 2009 09:38:06 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEA00BTHOZDYO90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 30 Jan 2009 09:38:06 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0UHc1LE004362 for ; Fri, 30 Jan 2009 09:38:01 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KEA00J01OQ47400@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 30 Jan 2009 09:38:01 -0800 (PST) Received: from [192.168.1.100] ([75.6.226.160]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KEA00LZOOYS7H10@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 30 Jan 2009 09:37:45 -0800 (PST) Date: Fri, 30 Jan 2009 09:37:11 -0800 From: Artem Kachitchkine Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4982c0a2.zazNTx7+UJg7B6HI%Joerg.Schilling@fokus.fraunhofer.de> Sender: Artem.Kachitchkin@sun.com To: Joerg Schilling Cc: PSARC-ext@sun.com Message-id: <49833AC7.8060501@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: <4981F0D8.2010400@sun.com> <4982c0a2.zazNTx7+UJg7B6HI%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 1296 > This would change the behavior. Do you plan to alternatively allow to > have the eject button blocked as before? Note that people may likke to have the > button locked in order to prevent to eject the media by accident. We provide an SMF property for rmvolmgr for this. There is no similar GConf property for the GNOME volume manager as far as I know, but it should be easy to send a patch upstream to add this. > BTW: cdrecord (when going to write to a CD / DVD / BD) loads the medium, > then locks the eject button and will not unlock the eject button before > the write process to the medium has been completed. Is there a potential > problem that could remove the lock from the eject button that has been > established by cdrecord and thus make cdrecord less reliable than before? The effect would be the same as issuing eject(1) command during cdrecord. The latest version of HAL provides interface locking: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#locking Applications like cdrecord can grab the lock for the duration of the critical operation, which would prevent any DBus method from being called on the locked interface, including Eject() method. HAL in Solaris, however, needs to be upgraded to the latest version to get this functionality. -Artem From Joerg.Schilling@fokus.fraunhofer.de Mon Feb 2 05:56:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n12DuAQr023579 for ; Mon, 2 Feb 2009 05:56:11 -0800 (PST) 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 n12Du89M015756; Mon, 2 Feb 2009 05:56:10 -0800 (PST) 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 <0KEF00A1FYPLZR00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 02 Feb 2009 05:56:09 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEF006AOYPKSDB0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 02 Feb 2009 05:56:09 -0800 (PST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n12DduDB029939; Mon, 02 Feb 2009 13:56:08 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay12i.sun.com with ESMTP id BT-MMP-1661790; Mon, 02 Feb 2009 13:56:08 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-6953778; Mon, 02 Feb 2009 13:56:06 +0000 (Z) Received: from iron02.fraunhofer.de ([153.96.1.56] [153.96.1.56]) by relay1i.sun.com with ESMTP id BT-MMP-39407761; Mon, 02 Feb 2009 13:56:06 +0000 (Z) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by iron02.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; Mon, 02 Feb 2009 14:56:05 +0100 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id n12Du4rF009896; Mon, 02 Feb 2009 14:56:05 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 02 Feb 2009 14:56:05 +0100 Date: Mon, 02 Feb 2009 14:56:04 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <49833AC7.8060501@sun.com> To: Artem.Kachitchkin@sun.com Cc: PSARC-ext@sun.com Message-id: <4986fb74.ZuDOXAzH/bu6k0mo%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.6/5.0, scanned in 1.219sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4981F0D8.2010400@sun.com> <4982c0a2.zazNTx7+UJg7B6HI%Joerg.Schilling@fokus.fraunhofer.de> <49833AC7.8060501@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 02 Feb 2009 13:56:05.0238 (UTC) FILETIME=[FDAF1960:01C9853D] Status: RO Content-Length: 1421 Artem Kachitchkine wrote: > > BTW: cdrecord (when going to write to a CD / DVD / BD) loads the medium, > > then locks the eject button and will not unlock the eject button before > > the write process to the medium has been completed. Is there a potential > > problem that could remove the lock from the eject button that has been > > established by cdrecord and thus make cdrecord less reliable than before? > > The effect would be the same as issuing eject(1) command during cdrecord. > > The latest version of HAL provides interface locking: > > http://people.freedesktop.org/~david/hal-spec/hal-spec.html#locking > > Applications like cdrecord can grab the lock for the duration of the > critical operation, which would prevent any DBus method from being > called on the locked interface, including Eject() method. HAL in > Solaris, however, needs to be upgraded to the latest version to get this > functionality. Do you know when this will happen? Do you know whether this will allow to force to unmount a filesystem in order to allow cdrecord to add another session to the medium? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Artem.Kachitchkin@sun.com Mon Feb 2 11:57:09 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n12Jv9I2023347 for ; Mon, 2 Feb 2009 11:57:09 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n12Jv2Zx019786 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Feb 2009 11:57:09 -0800 (PST) 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 <0KEG00H0PFF8KT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Feb 2009 12:57:08 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEG008W4FF3S9B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Feb 2009 12:57:07 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n12Jv2pQ014246 for ; Mon, 02 Feb 2009 11:57:02 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KEG00M01ELU9N00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Feb 2009 11:57:02 -0800 (PST) Received: from [129.146.104.83] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KEG00L3OFESJ620@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Feb 2009 11:56:57 -0800 (PST) Date: Mon, 02 Feb 2009 11:55:40 -0800 From: Artem Kachitchkine Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4986fb74.ZuDOXAzH/bu6k0mo%Joerg.Schilling@fokus.fraunhofer.de> Sender: Artem.Kachitchkin@sun.com To: Joerg Schilling Cc: PSARC-ext@sun.com Message-id: <49874FBC.4070905@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: <4981F0D8.2010400@sun.com> <4982c0a2.zazNTx7+UJg7B6HI%Joerg.Schilling@fokus.fraunhofer.de> <49833AC7.8060501@sun.com> <4986fb74.ZuDOXAzH/bu6k0mo%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 909 On 02/02/09 05:56, Joerg Schilling wrote: >> The latest version of HAL provides interface locking: >> >> http://people.freedesktop.org/~david/hal-spec/hal-spec.html#locking >> >> Applications like cdrecord can grab the lock for the duration of the >> critical operation, which would prevent any DBus method from being >> called on the locked interface, including Eject() method. HAL in >> Solaris, however, needs to be upgraded to the latest version to get this >> functionality. > > Do you know when this will happen? No. Perhaps the current HAL owner can provide more info. We should also keep in mind that HAL is likely to be replaced with DeviceKit in not so distant future. > Do you know whether this will allow to force to unmount a filesystem > in order to allow cdrecord to add another session to the medium? Locking does not affect this. Applications can use the Unmount() method. -Artem From Artem.Kachitchkin@sun.com Mon Feb 9 14:29:29 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n19MTT6o002702 for ; Mon, 9 Feb 2009 14:29:29 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n19MTRVs019913 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 9 Feb 2009 22:29:28 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KET00C05L53ZU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Feb 2009 14:29:27 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KET009Z6L521C20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Feb 2009 14:29:26 -0800 (PST) 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 n19MTQ4v003836 for ; Mon, 09 Feb 2009 14:29:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KET00B00KDTDM00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Feb 2009 14:29:26 -0800 (PST) Received: from [129.146.104.83] ([unknown] [129.146.104.83]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KET00A8XL4G5800@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Feb 2009 14:29:04 -0800 (PST) Date: Mon, 09 Feb 2009 14:28:10 -0800 From: Artem Kachitchkine Subject: Re: PSARC/2009/058 physical eject button In-reply-to: <4981F0D8.2010400@sun.com> Sender: Artem.Kachitchkin@sun.com To: PSARC-ext@sun.com Message-id: <4990ADFA.8070800@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: <4981F0D8.2010400@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 220 This case is now approved. The only change to the initial proposal is that the default value of the "eject_button" SMF property for rmvolmgr will now be boolean true, rather than false, as discussed earlier. -Artem