From gd78059@sac.sfbay.sun.com Tue Dec 1 15:20:33 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 nB1NKXox013626 for ; Tue, 1 Dec 2009 15:20:33 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1NKWSv028775; Tue, 1 Dec 2009 15:20:32 -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 <0KTZ0050HY68RO00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 01 Dec 2009 15:20:32 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTZ00G4NY687060@nwk-avmta-1.sfbay.Sun.COM>; Tue, 01 Dec 2009 15:20:32 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB1NKWQF013399; Tue, 01 Dec 2009 15:20:32 -0800 (PST) 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 nB1NKVjf013621; Tue, 01 Dec 2009 15:20:31 -0800 (PST) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nB1NKUDY013617; Tue, 01 Dec 2009 15:20:30 -0800 (PST) Date: Tue, 01 Dec 2009 15:20:30 -0800 (PST) From: "Garrett D'Amore - sun microsystems" Subject: DKIOCREADONLY [PSARC/2009/656 FastTrack timeout 12/07/2009] To: PSARC-ext@sun.com Cc: Garrett.Damore@sun.com Message-id: <200912012320.nB1NKUDY013617@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1963 The following case is so obvious that it could possibly be scoped as an automatic case. However, given that it is introducing a new Committed ioctl, its a fast-track. - Garrett Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: DKIOCREADONLY 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 01 December, 2009 4. Technical Description Currently, the "hal" daemon that is responsible for automatically mounting media is unable to mount read-only SDcard (write protect tab enabled) media, because it has no way to detect this media needs to be mounted read only. (hal is implemented with run-time checks for floppy media, and with a hard coded rule for CDROM media.) What is needed is a generic run-time check via an ioctl, that hal can use to determine if it is appropriate to perform a read-only mount. Therefore, we propose a new ioctl code be added to dkio(7I), as follows (note that this is in the style of the existing man page, which is technically not quite right): DKIOCREADONLY The argument to this ioctl() is an integer. After suc- cessful completion, this ioctl() sets that integer to a non-zero value if the drive in question has read-only media. If the media is writable, or not present, the integer is set to 0. (Technically, the argument is *pointer* to an integer, but that's true for the other ioctls documented in dkio(7D).) Note that sd(7D) does not currently implement this, and will return an errno (ENOTTY, I believe). We request "patch" binding for this ioctl (although we have no plans to backport), and Committed stability level. 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 Artem.Kachitchkin@sun.com Tue Dec 1 16:25:09 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB20P9YD016546 for ; Tue, 1 Dec 2009 16:25:09 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB20P8Aw013602 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Dec 2009 18:25:08 -0600 (CST) 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 <0KU00040715WHX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 01 Dec 2009 17:25:08 -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 <0KU000D0J15V9LA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 01 Dec 2009 17:25:07 -0700 (MST) 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 nB20P6ZD011835 for ; Tue, 01 Dec 2009 16:25:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU000E000PWOV00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 01 Dec 2009 16:25:06 -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 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU000CKY15USQ30@fe-sfbay-10.sun.com>; Tue, 01 Dec 2009 16:25:06 -0800 (PST) Date: Tue, 01 Dec 2009 16:25:09 -0800 From: Artem Kachitchkine Subject: Re: DKIOCREADONLY [PSARC/2009/656 FastTrack timeout 12/07/2009] In-reply-to: <200912012320.nB1NKUDY013617@sac.sfbay.sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: <4B15B3E5.9040005@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912012320.nB1NKUDY013617@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 993 > Currently, the "hal" daemon that is responsible for automatically mounting > media is unable to mount read-only SDcard (write protect tab enabled) media, > because it has no way to detect this media needs to be mounted read only. > (hal is implemented with run-time checks for floppy media, and with a hard > coded rule for CDROM media.) It's been a while since I wrote that HAL code, but just by looking at sd now, it appears that the way to detect write protected media is to attempt to open(2) it for writing. Sd would send the MODE SENSE command and check the WP bit - if set, open would fail with EROFS. I'm not sure why I didn't use that in hald-probe-storage. There might have been undesirable side-effects of opening sd for writing. DKIOCREADONLY has the advantage of being usable even when device is opened read-only, so +1 on the proposal. > Note that sd(7D) does not currently implement this, and will return > an errno (ENOTTY, I believe). sd`sr_check_wp() ? -Artem From Harry.Lu@sun.com Tue Dec 1 19:13:59 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 nB23DxSl021094 for ; Tue, 1 Dec 2009 19:13:59 -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.4) with ESMTP id nB23Dw5F002191 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Dec 2009 20:13:58 -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 <0KU000N058ZA3P00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Dec 2009 20:13:58 -0700 (MST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU000ETS8Z9QD30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Dec 2009 20:13:58 -0700 (MST) 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 nB23DuWd007211 for ; Wed, 02 Dec 2009 03:13:56 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU0005008Z53V00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Dec 2009 11:13:56 +0800 (SGT) Received: from [129.158.217.161] ([unknown] [129.158.217.161]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU000IK88Z70WI0@mail-apac.sun.com>; Wed, 02 Dec 2009 11:13:56 +0800 (SGT) Date: Wed, 02 Dec 2009 11:13:36 +0800 From: Harry Lu Subject: Re: DKIOCREADONLY [PSARC/2009/656 FastTrack timeout 12/07/2009] In-reply-to: <200912012320.nB1NKUDY013617@sac.sfbay.sun.com> Sender: Harry.Lu@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: <1259723616.2799.4.camel@fulltime> MIME-version: 1.0 X-Mailer: Evolution 2.26.1.1 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912012320.nB1NKUDY013617@sac.sfbay.sun.com> Status: RO Content-Length: 2459 Will the new interface be used to fix http://defect.opensolaris.org/bz/show_bug.cgi?id=252 ? Thanks, Harry On Tue, 2009-12-01 at 15:20 -0800, Garrett D'Amore - sun microsystems wrote: > The following case is so obvious that it could possibly be scoped as an > automatic case. However, given that it is introducing a new Committed > ioctl, its a fast-track. > > - Garrett > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > DKIOCREADONLY > 1.2. Name of Document Author/Supplier: > Author: Garrett D'Amore > 1.3 Date of This Document: > 01 December, 2009 > 4. Technical Description > > Currently, the "hal" daemon that is responsible for automatically mounting > media is unable to mount read-only SDcard (write protect tab enabled) media, > because it has no way to detect this media needs to be mounted read only. > (hal is implemented with run-time checks for floppy media, and with a hard > coded rule for CDROM media.) > > What is needed is a generic run-time check via an ioctl, that hal can use > to determine if it is appropriate to perform a read-only mount. > > Therefore, we propose a new ioctl code be added to dkio(7I), as follows > (note that this is in the style of the existing man page, which is technically > not quite right): > > DKIOCREADONLY > > The argument to this ioctl() is an integer. After suc- > cessful completion, this ioctl() sets that integer to > a non-zero value if the drive in question has read-only > media. If the media is writable, or not present, the > integer is set to 0. > > (Technically, the argument is *pointer* to an integer, but that's true > for the other ioctls documented in dkio(7D).) > > Note that sd(7D) does not currently implement this, and will return > an errno (ENOTTY, I believe). > > We request "patch" binding for this ioctl (although we have no plans to > backport), and Committed stability level. > > > 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 > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org -- Harry.Lu@Sun.COM OpenSolaris Desktop Group, Sun Microsystems Phone ext. 82870 From Garrett.Damore@sun.com Tue Dec 1 21:18:45 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB25IjeW023152 for ; Tue, 1 Dec 2009 21:18:45 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB25IiOc006244 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Dec 2009 23:18:44 -0600 (CST) 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 <0KU000505ER8AW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Dec 2009 21:18:44 -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 <0KU0007BPER7S1D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Dec 2009 21:18:43 -0800 (PST) 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 nB25IhOR025290 for ; Tue, 01 Dec 2009 21:18:43 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU000H00EKE9Y00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Dec 2009 21:18:43 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU0007K3ER7TYC0@fe-sfbay-09.sun.com>; Tue, 01 Dec 2009 21:18:43 -0800 (PST) Date: Tue, 01 Dec 2009 21:18:42 -0800 From: "Garrett D'Amore" Subject: Re: DKIOCREADONLY [PSARC/2009/656 FastTrack timeout 12/07/2009] In-reply-to: <1259723616.2799.4.camel@fulltime> Sender: Garrett.Damore@sun.com To: Harry Lu Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4B15F8B2.3090906@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912012320.nB1NKUDY013617@sac.sfbay.sun.com> <1259723616.2799.4.camel@fulltime> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 2609 Harry Lu wrote: > Will the new interface be used to fix > http://defect.opensolaris.org/bz/show_bug.cgi?id=252 ? > Potentially, yes. Although I've not modified the "sd" driver in my prototype to return this, that is indeed the correct fix. - Garrett > Thanks, > Harry > > On Tue, 2009-12-01 at 15:20 -0800, Garrett D'Amore - sun microsystems > wrote: > >> The following case is so obvious that it could possibly be scoped as an >> automatic case. However, given that it is introducing a new Committed >> ioctl, its a fast-track. >> >> - Garrett >> >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> DKIOCREADONLY >> 1.2. Name of Document Author/Supplier: >> Author: Garrett D'Amore >> 1.3 Date of This Document: >> 01 December, 2009 >> 4. Technical Description >> >> Currently, the "hal" daemon that is responsible for automatically mounting >> media is unable to mount read-only SDcard (write protect tab enabled) media, >> because it has no way to detect this media needs to be mounted read only. >> (hal is implemented with run-time checks for floppy media, and with a hard >> coded rule for CDROM media.) >> >> What is needed is a generic run-time check via an ioctl, that hal can use >> to determine if it is appropriate to perform a read-only mount. >> >> Therefore, we propose a new ioctl code be added to dkio(7I), as follows >> (note that this is in the style of the existing man page, which is technically >> not quite right): >> >> DKIOCREADONLY >> >> The argument to this ioctl() is an integer. After suc- >> cessful completion, this ioctl() sets that integer to >> a non-zero value if the drive in question has read-only >> media. If the media is writable, or not present, the >> integer is set to 0. >> >> (Technically, the argument is *pointer* to an integer, but that's true >> for the other ioctls documented in dkio(7D).) >> >> Note that sd(7D) does not currently implement this, and will return >> an errno (ENOTTY, I believe). >> >> We request "patch" binding for this ioctl (although we have no plans to >> backport), and Committed stability level. >> >> >> 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 >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> From Darren.Moffat@sun.com Mon Dec 7 08:00:37 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7G0af4025416 for ; Mon, 7 Dec 2009 08:00:36 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7G0ZMQ017837 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Dec 2009 10:00:36 -0600 (CST) 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 <0KUA00J0VHSZ2T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 08:00:35 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUA00IRLHSX9PC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 08:00:34 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7G0W0f007052 for ; Mon, 07 Dec 2009 16:00:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUA00B00GQOKN00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 16:00:23 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUA007GJHSFNV20@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 16:00:15 +0000 (GMT) Date: Mon, 07 Dec 2009 16:00:15 +0000 From: Darren J Moffat Subject: PSARC/2009/656 DKIOCREADONLY Sender: Darren.Moffat@sun.com To: PSARC-ext@sun.com Message-id: <4B1D268F.4040905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 329 This case looks reasonable as specified, however I do have one question. Given hal is (or at least has been) used on Linux/BSD systems do they already have this or a similar ioctl ? Is there any value in being compatible or is this an area where HAL is supposed to be operating system specific anyway ? -- Darren J Moffat From gdamore@sun.com Mon Dec 7 08:10:34 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7GAYEr025571 for ; Mon, 7 Dec 2009 08:10:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7GAXEf024765 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Dec 2009 10:10:34 -0600 (CST) 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 <0KUA00F1HI9LSY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 07 Dec 2009 09:10:33 -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 <0KUA00CH0I9JWG20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 07 Dec 2009 09:10:31 -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 nB7GAVh1023525 for ; Mon, 07 Dec 2009 08:10:31 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUA00C00I7OUA00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 07 Dec 2009 08:10:31 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUA00E8BI9I9XE0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 07 Dec 2009 08:10:30 -0800 (PST) Date: Mon, 07 Dec 2009 08:10:29 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2009/656 DKIOCREADONLY In-reply-to: <4B1D268F.4040905@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <4B1D28F5.6080801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B1D268F.4040905@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 793 Darren J Moffat wrote: > This case looks reasonable as specified, however I do have one question. > > Given hal is (or at least has been) used on Linux/BSD systems do they > already have this or a similar ioctl ? Is there any value in being > compatible or is this an area where HAL is supposed to be operating > system specific anyway ? > The change I'm making is in the solaris-specific implementation component of HAL. If Linux supports dkio(7I) at all, its news to me. Certainly, I don't believe that it supports DKIOCSTATE, which is the main dkio(7I) functionality in this part of hal. I did a search of Linux source (not entirely exhaustive, but it included the "block" subdirectory and the include/ subdirectory) at least, and could not find any such ioctls. - Garrett From Darren.Moffat@sun.com Mon Dec 7 08:13:51 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7GDpYe025611 for ; Mon, 7 Dec 2009 08:13:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7GDoV8027173 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Dec 2009 10:13:51 -0600 (CST) 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 <0KUA00L0FIF2EK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 07 Dec 2009 08:13:50 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUA00IDIIF09HD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 07 Dec 2009 08:13:49 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7GDluN008715 for ; Mon, 07 Dec 2009 16:13:48 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUA00E00HOLRF00@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 07 Dec 2009 16:13:40 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUA00CHIIEM4XB0@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 07 Dec 2009 16:13:35 +0000 (GMT) Date: Mon, 07 Dec 2009 16:13:34 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/656 DKIOCREADONLY In-reply-to: <4B1D28F5.6080801@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <4B1D29AE.2040202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B1D268F.4040905@Sun.COM> <4B1D28F5.6080801@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 1010 Garrett D'Amore wrote: > Darren J Moffat wrote: >> This case looks reasonable as specified, however I do have one question. >> >> Given hal is (or at least has been) used on Linux/BSD systems do they >> already have this or a similar ioctl ? Is there any value in being >> compatible or is this an area where HAL is supposed to be operating >> system specific anyway ? >> > The change I'm making is in the solaris-specific implementation > component of HAL. If Linux supports dkio(7I) at all, its news to me. > Certainly, I don't believe that it supports DKIOCSTATE, which is the > main dkio(7I) functionality in this part of hal. > > I did a search of Linux source (not entirely exhaustive, but it included > the "block" subdirectory and the include/ subdirectory) at least, and > could not find any such ioctls. Given that I'm happy you have done the due dilligence of comparing the problem space with another system and I'm happy to give my +1 for the case as specified. -- Darren J Moffat From gdamore@sun.com Tue Dec 8 07:39:10 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB8FdA1P009318 for ; Tue, 8 Dec 2009 07:39:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB8Fd9ot031982 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Dec 2009 08:39:09 -0700 (MST) 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 <0KUC00005BH9NM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 07:39:09 -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 <0KUC00JFPBH9BI90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 07:39:09 -0800 (PST) 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 nB8Fd9Da020018 for ; Tue, 08 Dec 2009 07:39:09 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUC00600BE92600@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 07:39:09 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUC004KKBH89I90@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 07:39:09 -0800 (PST) Date: Tue, 08 Dec 2009 07:39:08 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2009/656 DKIOCREADONLY In-reply-to: <4B1D29AE.2040202@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <4B1E731C.9050709@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B1D268F.4040905@Sun.COM> <4B1D28F5.6080801@sun.com> <4B1D29AE.2040202@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1182 Darren J Moffat wrote: > Garrett D'Amore wrote: >> Darren J Moffat wrote: >>> This case looks reasonable as specified, however I do have one >>> question. >>> >>> Given hal is (or at least has been) used on Linux/BSD systems do >>> they already have this or a similar ioctl ? Is there any value in >>> being compatible or is this an area where HAL is supposed to be >>> operating system specific anyway ? >>> >> The change I'm making is in the solaris-specific implementation >> component of HAL. If Linux supports dkio(7I) at all, its news to >> me. Certainly, I don't believe that it supports DKIOCSTATE, which is >> the main dkio(7I) functionality in this part of hal. >> >> I did a search of Linux source (not entirely exhaustive, but it >> included the "block" subdirectory and the include/ subdirectory) at >> least, and could not find any such ioctls. > > Given that I'm happy you have done the due dilligence of comparing the > problem space with another system and I'm happy to give my +1 for the > case as specified. > And with that, this case, having reached consensus with a +1 and having reached its time out, is hereby closed approved. - Garrett