From Garrett.Damore@sun.com Sun May 13 23:57:17 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4E6vGJM022028 for ; Sun, 13 May 2007 23:57:17 -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 l4E6u8OY025972 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Mon, 14 May 2007 14:56:09 +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 <0JI000003R9K0P00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 13 May 2007 23:56:08 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JI000KCZR9KSC20@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 13 May 2007 23:56:08 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4E6u8Nb016040 for ; Sun, 13 May 2007 23:56:08 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JI000K01R6ZX300@d1-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 13 May 2007 23:56:08 -0700 (PDT) Received: from [129.150.12.94] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JI00030IR9KW2ME@d1-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sun, 13 May 2007 23:56:08 -0700 (PDT) Date: Sun, 13 May 2007 23:56:16 -0700 From: "Garrett D'Amore" Subject: 2007/270 EOF hme/fas headers Sender: Garrett.Damore@sun.com To: psarc-ext@sun.com Message-id: <46480810.3030009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2410 I'm filing the following case on my own behalf. (My first case! :-) This case proposes to remove some device header files that do not provide any useful interface, and only provide definitions useful internally to the drivers for which they belong. Release binding is Micro (although I'm only actually intending to make this change for Nevada). See the explanation on the binding in the text below. I think this qualifies for self-review, but as I'm still new to the process, maybe someone else will disagree. For now I'm marking it "closed approved automatic", feel free to correct this if I've got it wrong. :-) Problem ------- The package SUNWhmdu delivers a few header files, which with one notable exception, are only useful to within the fas and hme device drivers. That one exception, is the HME_IOC ioctls, which can be used to manage the link speed and duplex on hme devices. However, this is redundant functionality to what is already provided by NDD (which itself will be replaced by forthcoming Brussels and HME conversion to GLDv3). Further, these ioctls have no known consumers, are not documented, and do not appear to be covered by any contracted interface. (Visual inspection of the only likely candidate consumer, the SunVTS hme test, confirms that it uses NDD ioctls.) The full set of header files delivered is: * sys/hme.h * sys/hme_mac.h * sys/hme_phy.h * sys/scsi/adapters/fascmd.h * sys/scsi/adapters/fasdma.h * sys/scsi/adapters/fasreg.h * sys/scsi/adapters/fasvar.h Proposed Solution ----------------- As part of a general cleanup surrounding the hme and qfe device drivers, we propose to eliminate the SUNWhmdu package. None of the above headers are required, and it should be safe to simply remove them. It is not clear that this requires any release note to be published at all. Note: It is not even clear that this case has any ARC impact at all, since none of the headers are part of any documented API. Note on Binding --------------- In most cases, this would a reasonable thing to request patch binding for. However, we understand that removal of a package in a patch is not supported. Furthermore, apart from the disk space used by the files themselves, there is little benefit in removing these headers from a deployed installation. Therefore, Micro binding is sufficient to our needs.