From cth@sac.sfbay.sun.com Tue Oct 9 15:34: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 l99MYGju020027 for ; Tue, 9 Oct 2007 15:34: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 l99MUrQS012685; Wed, 10 Oct 2007 06:31:00 +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 <0JPO00L0J17LRZ00@nwk-avmta-2.sfbay.sun.com>; Tue, 09 Oct 2007 15:30:57 -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 <0JPO00JJL17KYP30@nwk-avmta-2.sfbay.sun.com>; Tue, 09 Oct 2007 15:30:56 -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 l99MUsxH006259; Tue, 09 Oct 2007 15:30:54 -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 l99MY7DY020018; Tue, 09 Oct 2007 15:34:07 -0700 (PDT) Received: (from cth@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l99MY7lx020014; Tue, 09 Oct 2007 15:34:07 -0700 (PDT) Date: Tue, 09 Oct 2007 15:34:07 -0700 (PDT) From: Christopher Horne Subject: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] To: PSARC-ext@sun.com Cc: chris.horne@sun.com, eric.taylor@sun.com, grant.zhang@sun.com, mark.johnson@sun.com, randall.ralphs@sun.com Message-id: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5717 I am sponsoring the following fasttrack for Mark Johnson, requesting patch binding and a timeout of 10/16/2007. -Chris Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI 1. Introduction 1.1 Project/Component Working Name: bp_copyin()/bp_copyout() 1.2 Name of Document Author/Supplier: Author: Mark Johnson 1.3 Date of This Document: Tue Oct 9 10:36:08 MDT 2007 4. Technical Description 4.1 Introduction This case introduces two new buf interfaces, and is the second of two fasttracks to address st tape driver performance on x86. dma-max-arch scsi capability bp_copyin()/bp_copyout() There is a recently escalated bug outstanding for this issue. 6567168 s10 x86 st tape driver performance issue http://monaco.sfbay/detail.jsf?cr=6567168 4.2 Background Most tape drives cannot handle partial DMAs. An entire tape block must be transferred in a single DMA. For our SPARC based systems, this is relatively simple. Since these systems have an IOMMU, the only real consideration is the underlying HBA's maximum DMA size, which is returned via the 'dma-max' scsi capability. For current x86 bases systems, this becomes more complicated. Not only can the maximum DMA be limited by the underlying HBA's maximum DMA size, but it can also be limited by the DMA engines scatter/gather list constraints (if the memory is completely fragmented). Today on x86, the st tape driver will allocate physically contiguous memory and then bp_mapin/bcopy/bp_mapout all transfers where the tape blocksize is greater than 64KBytes. There are two parts to the solution. The first is to provide a way for the st driver to query what the DMA constraints of the HBA are, taking the sgllen into account. The second is to provide a 64-bit optimized bp copy for block sizes which are too large to fit within the HBA's sgllen constraints, but are within the HBA's maximum DMA size. For example, the ST driver may find out that the maximum DMA supported by the HBA ('dma-max') is 4M and the maximum DMA supported by the HBA/system is 1M ('dma-max-arch'). The st driver can then allow any blocksize <= 1M to go directly to the HBA and then use the optimized copy for block sizes greater than 1M and less than or equal to 4M. Today it does an un-optimized copy for block sizes greater than 64K. This case addresses the second part of the problem. It provides two new general purpose buf routines to copy data in and out of bufs. These routines are supported on all architectures. Some implementation notes of interest. The routines will first look to see if the buf has already been mapped info kernel VA space. If not, they implement an optimized copy on 64-bit kernels using seg kpm. 4.3 Interface Table INTERFACE COMMITMENT LEVEL COMMENT bp_copyin(9F) Committed optimize bp_mapin, bcopy, bp_copyout(9F) Committed bp_mapout. 4.4 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 6.6. ARC Exposure: open A.1 man page for bp_copyin(9F) Kernel Functions for Drivers bp_copyin(9F) NAME bp_copyin - copy from a kernel virtual address to a buf SYNOPSIS #include #include int bp_copyin(caddr_t vaddr, struct buf *bp, offset_t offset, size_t size); INTERFACE LEVEL Architecture independent level 1 (DDI/DKI). PARAMETERS vaddr Kernel virtual address to copy from. bp Pointer to the buffer header structure to copy to. offset Offset into bp where to start copying. size Size of copy. DESCRIPTION bp_copyin() copies 'size' bytes starting from kernel virtual address 'vaddr' to 'offset' bytes into the memory associated with 'bp'. The 'offset' only applies to 'bp'. RETURN VALUES Under normal conditions, 0 is returned to indicate a successful copy. Otherwise, -1 is returned if 'bp' references invalid pages. CONTEXT bp_copyin() can be called from user or kernel context only. SEE ALSO bp_copyout(9F), buf(9S), ddi_copyin(9F), bp_mapin(9F), bp_mapout(9F). A.2 man page for bp_copyout(9F) Kernel Functions for Drivers bp_copyout(9F) NAME bp_copyout - copy from a buf to a kernel virtual address SYNOPSIS #include #include int bp_copyout(struct buf *bp, caddr_t vaddr, offset_t offset, size_t size); INTERFACE LEVEL Architecture independent level 1 (DDI/DKI). PARAMETERS bp Pointer to the buffer header structure to copy from. vaddr Kernel virtual address to copy to. offset Offset into bp where to start copying. size Size of copy. DESCRIPTION bp_copyput() copies 'size' bytes starting at 'offset' bytes into the memory associated with 'bp' to the destination address kernel virtual address 'vaddr'. The 'offset' only applies to 'bp'. RETURN VALUES Under normal conditions, 0 is returned to indicate a successful copy. Otherwise, -1 is returned if 'bp' references invalid pages. CONTEXT bp_copyout() can be called from user or kernel context only. SEE ALSO bp_copyin(9F), buf(9S), ddi_copyout(9F), bp_mapin(9F), bp_mapout(9F). From gdamore@sun.com Tue Oct 9 21:04:44 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 l9A44hPD025754 for ; Tue, 9 Oct 2007 21:04:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9A41CG1003650 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Oct 2007 12:01:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPO00201GIE5300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 09 Oct 2007 21:01:26 -0700 (PDT) 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 <0JPO00B7HGIDM880@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 09 Oct 2007 21:01:25 -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 l9A41PIE011642 for ; Tue, 09 Oct 2007 21:01:25 -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 <0JPO00801GCK0Q00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 09 Oct 2007 21:01:25 -0700 (PDT) Received: from [192.168.251.11] ([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 <0JPO00K4JGICXFF0@fe-sfbay-10.sun.com>; Tue, 09 Oct 2007 21:01:25 -0700 (PDT) Date: Tue, 09 Oct 2007 20:59:06 -0700 From: "Garrett D'Amore" Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Christopher Horne Cc: PSARC-ext@sun.com, Chris.Horne@sun.com, Eric.Taylor@sun.com, Grant.Zhang@sun.com, Mark.Johnson@sun.com, Randall.Ralphs@sun.com Message-id: <470C4E0A.3030508@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 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 6604 I find the nomenclature here a bit confusing. ddi_copyin or copyin are most often used to copy from user space *in* to kernel space. ddi_copyout or copyout likewise usually reference copying data *out* from the kernel to user space. In otherwords, the "in/out" are normally used to in reference to kernel space. Your proposal, bp_copyin makes the "in" for this API in reference to the buf. (Which may or may not be userspace.) I find the reversal of the point of reference confusing. Does anyone else? -- Garrett Christopher Horne wrote: > I am sponsoring the following fasttrack for Mark Johnson, requesting patch > binding and a timeout of 10/16/2007. > > -Chris > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > > 1. Introduction > 1.1 Project/Component Working Name: > > bp_copyin()/bp_copyout() > > 1.2 Name of Document Author/Supplier: > > Author: Mark Johnson > > 1.3 Date of This Document: > > Tue Oct 9 10:36:08 MDT 2007 > > 4. Technical Description > > 4.1 Introduction > > This case introduces two new buf interfaces, and is the second of > two fasttracks to address st tape driver performance on x86. > > dma-max-arch scsi capability > bp_copyin()/bp_copyout() > > There is a recently escalated bug outstanding for this issue. > > 6567168 s10 x86 st tape driver performance issue > http://monaco.sfbay/detail.jsf?cr=6567168 > > 4.2 Background > > Most tape drives cannot handle partial DMAs. An entire tape block > must be transferred in a single DMA. > > For our SPARC based systems, this is relatively simple. Since > these systems have an IOMMU, the only real consideration is the > underlying HBA's maximum DMA size, which is returned via the > 'dma-max' scsi capability. > > For current x86 bases systems, this becomes more complicated. Not > only can the maximum DMA be limited by the underlying HBA's maximum > DMA size, but it can also be limited by the DMA engines > scatter/gather list constraints (if the memory is completely > fragmented). > > Today on x86, the st tape driver will allocate physically > contiguous memory and then bp_mapin/bcopy/bp_mapout all transfers > where the tape blocksize is greater than 64KBytes. > > There are two parts to the solution. The first is to provide a way > for the st driver to query what the DMA constraints of the HBA are, > taking the sgllen into account. The second is to provide a 64-bit > optimized bp copy for block sizes which are too large to fit within > the HBA's sgllen constraints, but are within the HBA's maximum DMA > size. > > For example, the ST driver may find out that the maximum DMA > supported by the HBA ('dma-max') is 4M and the maximum DMA supported > by the HBA/system is 1M ('dma-max-arch'). The st driver can then > allow any blocksize <= 1M to go directly to the HBA and then use > the optimized copy for block sizes greater than 1M and less than or > equal to 4M. Today it does an un-optimized copy for block sizes > greater than 64K. > > This case addresses the second part of the problem. It provides two > new general purpose buf routines to copy data in and out of bufs. > These routines are supported on all architectures. > > Some implementation notes of interest. The routines will first look > to see if the buf has already been mapped info kernel VA space. If > not, they implement an optimized copy on 64-bit kernels using seg > kpm. > > > 4.3 Interface Table > > INTERFACE COMMITMENT LEVEL COMMENT > > bp_copyin(9F) Committed optimize bp_mapin, bcopy, > bp_copyout(9F) Committed bp_mapout. > > 4.4 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 > 6.6. ARC Exposure: open > > > > A.1 man page for bp_copyin(9F) > > Kernel Functions for Drivers bp_copyin(9F) > > NAME > bp_copyin - copy from a kernel virtual address to a buf > > SYNOPSIS > #include > #include > > int bp_copyin(caddr_t vaddr, struct buf *bp, > offset_t offset, size_t size); > > INTERFACE LEVEL > Architecture independent level 1 (DDI/DKI). > > PARAMETERS > vaddr Kernel virtual address to copy from. > > bp Pointer to the buffer header structure to copy to. > > offset Offset into bp where to start copying. > > size Size of copy. > > DESCRIPTION > bp_copyin() copies 'size' bytes starting from kernel virtual > address 'vaddr' to 'offset' bytes into the memory associated > with 'bp'. The 'offset' only applies to 'bp'. > > RETURN VALUES > Under normal conditions, 0 is returned to indicate a > successful copy. Otherwise, -1 is returned if 'bp' references > invalid pages. > > CONTEXT > bp_copyin() can be called from user or kernel context only. > > SEE ALSO > bp_copyout(9F), buf(9S), ddi_copyin(9F), bp_mapin(9F), > bp_mapout(9F). > > A.2 man page for bp_copyout(9F) > > Kernel Functions for Drivers bp_copyout(9F) > > NAME > bp_copyout - copy from a buf to a kernel virtual address > > SYNOPSIS > #include > #include > > int bp_copyout(struct buf *bp, caddr_t vaddr, > offset_t offset, size_t size); > > INTERFACE LEVEL > Architecture independent level 1 (DDI/DKI). > > PARAMETERS > bp Pointer to the buffer header structure to copy from. > > vaddr Kernel virtual address to copy to. > > offset Offset into bp where to start copying. > > size Size of copy. > > DESCRIPTION > bp_copyput() copies 'size' bytes starting at 'offset' bytes > into the memory associated with 'bp' to the destination > address kernel virtual address 'vaddr'. The 'offset' only > applies to 'bp'. > > RETURN VALUES > Under normal conditions, 0 is returned to indicate a > successful copy. Otherwise, -1 is returned if 'bp' references > invalid pages. > > CONTEXT > bp_copyout() can be called from user or kernel context only. > > SEE ALSO > bp_copyin(9F), buf(9S), ddi_copyout(9F), bp_mapin(9F), > bp_mapout(9F). > From edward.pilatowicz@sun.com Tue Oct 9 23:50:59 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9A6owsq027598 for ; Tue, 9 Oct 2007 23:50:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9A6lWU2018152; Wed, 10 Oct 2007 07:47:35 +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 <0JPO0060JO79P800@nwk-avmta-2.sfbay.sun.com>; Tue, 09 Oct 2007 23:47:33 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPO003I7O78SA20@nwk-avmta-2.sfbay.sun.com>; Tue, 09 Oct 2007 23:47:32 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9A6lWVD967079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 09 Oct 2007 23:47:32 -0700 (PDT) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l9A6lWii967078; Tue, 09 Oct 2007 23:47:32 -0700 (PDT) Date: Tue, 09 Oct 2007 23:47:32 -0700 From: Edward Pilatowicz Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <470C4E0A.3030508@sun.com> To: "Garrett D'Amore" Cc: Christopher Horne , Chris.Horne@sun.com, Eric.Taylor@sun.com, PSARC-ext@sun.com, Mark.Johnson@sun.com, Randall.Ralphs@sun.com, Grant.Zhang@sun.com Message-id: <20071010064732.GW657152@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> <470C4E0A.3030508@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 7673 On Tue, Oct 09, 2007 at 08:59:06PM -0700, Garrett D'Amore wrote: > I find the nomenclature here a bit confusing. > > ddi_copyin or copyin are most often used to copy from user space *in* to > kernel space. > > ddi_copyout or copyout likewise usually reference copying data *out* > from the kernel to user space. > actually, iirc this isn't correct. ddi_copyin() will copy from userland -or- the kernel into the kernel. ddi_copyout() will copy from the kernel to userland -or- the kernel. this is why drivers should use these routies vs copyin() and copyout(). if drivers use copyin() and copyout() and they are not layering safe and can not be accessed from within the kernel via the ldi. these new bp "in/out" interfaces behave the same way the ddi "in/out" interfaces do, which (to me) makes complete sense to me. > In otherwords, the "in/out" are normally used to in reference to kernel > space. > > Your proposal, bp_copyin makes the "in" for this API in reference to the > buf. (Which may or may not be userspace.) > correct. i see no problem with this. ed > I find the reversal of the point of reference confusing. Does anyone else? > > -- Garrett > > Christopher Horne wrote: > > I am sponsoring the following fasttrack for Mark Johnson, requesting patch > > binding and a timeout of 10/16/2007. > > > > -Chris > > > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > > > > 1. Introduction > > 1.1 Project/Component Working Name: > > > > bp_copyin()/bp_copyout() > > > > 1.2 Name of Document Author/Supplier: > > > > Author: Mark Johnson > > > > 1.3 Date of This Document: > > > > Tue Oct 9 10:36:08 MDT 2007 > > > > 4. Technical Description > > > > 4.1 Introduction > > > > This case introduces two new buf interfaces, and is the second of > > two fasttracks to address st tape driver performance on x86. > > > > dma-max-arch scsi capability > > bp_copyin()/bp_copyout() > > > > There is a recently escalated bug outstanding for this issue. > > > > 6567168 s10 x86 st tape driver performance issue > > http://monaco.sfbay/detail.jsf?cr=6567168 > > > > 4.2 Background > > > > Most tape drives cannot handle partial DMAs. An entire tape block > > must be transferred in a single DMA. > > > > For our SPARC based systems, this is relatively simple. Since > > these systems have an IOMMU, the only real consideration is the > > underlying HBA's maximum DMA size, which is returned via the > > 'dma-max' scsi capability. > > > > For current x86 bases systems, this becomes more complicated. Not > > only can the maximum DMA be limited by the underlying HBA's maximum > > DMA size, but it can also be limited by the DMA engines > > scatter/gather list constraints (if the memory is completely > > fragmented). > > > > Today on x86, the st tape driver will allocate physically > > contiguous memory and then bp_mapin/bcopy/bp_mapout all transfers > > where the tape blocksize is greater than 64KBytes. > > > > There are two parts to the solution. The first is to provide a way > > for the st driver to query what the DMA constraints of the HBA are, > > taking the sgllen into account. The second is to provide a 64-bit > > optimized bp copy for block sizes which are too large to fit within > > the HBA's sgllen constraints, but are within the HBA's maximum DMA > > size. > > > > For example, the ST driver may find out that the maximum DMA > > supported by the HBA ('dma-max') is 4M and the maximum DMA supported > > by the HBA/system is 1M ('dma-max-arch'). The st driver can then > > allow any blocksize <= 1M to go directly to the HBA and then use > > the optimized copy for block sizes greater than 1M and less than or > > equal to 4M. Today it does an un-optimized copy for block sizes > > greater than 64K. > > > > This case addresses the second part of the problem. It provides two > > new general purpose buf routines to copy data in and out of bufs. > > These routines are supported on all architectures. > > > > Some implementation notes of interest. The routines will first look > > to see if the buf has already been mapped info kernel VA space. If > > not, they implement an optimized copy on 64-bit kernels using seg > > kpm. > > > > > > 4.3 Interface Table > > > > INTERFACE COMMITMENT LEVEL COMMENT > > > > bp_copyin(9F) Committed optimize bp_mapin, bcopy, > > bp_copyout(9F) Committed bp_mapout. > > > > 4.4 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 > > 6.6. ARC Exposure: open > > > > > > > > A.1 man page for bp_copyin(9F) > > > > Kernel Functions for Drivers bp_copyin(9F) > > > > NAME > > bp_copyin - copy from a kernel virtual address to a buf > > > > SYNOPSIS > > #include > > #include > > > > int bp_copyin(caddr_t vaddr, struct buf *bp, > > offset_t offset, size_t size); > > > > INTERFACE LEVEL > > Architecture independent level 1 (DDI/DKI). > > > > PARAMETERS > > vaddr Kernel virtual address to copy from. > > > > bp Pointer to the buffer header structure to copy to. > > > > offset Offset into bp where to start copying. > > > > size Size of copy. > > > > DESCRIPTION > > bp_copyin() copies 'size' bytes starting from kernel virtual > > address 'vaddr' to 'offset' bytes into the memory associated > > with 'bp'. The 'offset' only applies to 'bp'. > > > > RETURN VALUES > > Under normal conditions, 0 is returned to indicate a > > successful copy. Otherwise, -1 is returned if 'bp' references > > invalid pages. > > > > CONTEXT > > bp_copyin() can be called from user or kernel context only. > > > > SEE ALSO > > bp_copyout(9F), buf(9S), ddi_copyin(9F), bp_mapin(9F), > > bp_mapout(9F). > > > > A.2 man page for bp_copyout(9F) > > > > Kernel Functions for Drivers bp_copyout(9F) > > > > NAME > > bp_copyout - copy from a buf to a kernel virtual address > > > > SYNOPSIS > > #include > > #include > > > > int bp_copyout(struct buf *bp, caddr_t vaddr, > > offset_t offset, size_t size); > > > > INTERFACE LEVEL > > Architecture independent level 1 (DDI/DKI). > > > > PARAMETERS > > bp Pointer to the buffer header structure to copy from. > > > > vaddr Kernel virtual address to copy to. > > > > offset Offset into bp where to start copying. > > > > size Size of copy. > > > > DESCRIPTION > > bp_copyput() copies 'size' bytes starting at 'offset' bytes > > into the memory associated with 'bp' to the destination > > address kernel virtual address 'vaddr'. The 'offset' only > > applies to 'bp'. > > > > RETURN VALUES > > Under normal conditions, 0 is returned to indicate a > > successful copy. Otherwise, -1 is returned if 'bp' references > > invalid pages. > > > > CONTEXT > > bp_copyout() can be called from user or kernel context only. > > > > SEE ALSO > > bp_copyin(9F), buf(9S), ddi_copyout(9F), bp_mapin(9F), > > bp_mapout(9F). > > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From gdamore@sun.com Wed Oct 10 04:30:37 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 l9ABUaab002608 for ; Wed, 10 Oct 2007 04:30: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 l9ABRGGb021734 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Oct 2007 19:27:21 +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 <0JPP0000L15KPT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 04:27:20 -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 <0JPP00JM215KLC20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 04:27:20 -0700 (PDT) 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 l9ABRKH2022526 for ; Wed, 10 Oct 2007 04:27:20 -0700 (PDT) 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 <0JPP00L010ZEWV00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 04:27:20 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPP00CG215JCF50@fe-sfbay-09.sun.com>; Wed, 10 Oct 2007 04:27:19 -0700 (PDT) Date: Wed, 10 Oct 2007 04:24:59 -0700 From: "Garrett D'Amore" Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <20071010064732.GW657152@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: Christopher Horne , Chris.Horne@sun.com, Eric.Taylor@sun.com, PSARC-ext@sun.com, Mark.Johnson@sun.com, Randall.Ralphs@sun.com, Grant.Zhang@sun.com Message-id: <470CB68B.1010000@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 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> <470C4E0A.3030508@sun.com> <20071010064732.GW657152@eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 8627 Edward Pilatowicz wrote: > On Tue, Oct 09, 2007 at 08:59:06PM -0700, Garrett D'Amore wrote: > >> I find the nomenclature here a bit confusing. >> >> ddi_copyin or copyin are most often used to copy from user space *in* to >> kernel space. >> >> ddi_copyout or copyout likewise usually reference copying data *out* >> from the kernel to user space. >> >> > > actually, iirc this isn't correct. > > ddi_copyin() will copy from userland -or- the kernel into the kernel. > ddi_copyout() will copy from the kernel to userland -or- the kernel. > this is why drivers should use these routies vs copyin() and copyout(). > if drivers use copyin() and copyout() and they are not layering safe > and can not be accessed from within the kernel via the ldi. > Yes, that is the "in" or the "out" is taken relative to the kernel. The other side can be userspace, or kernel space (but is usually userspace). (You'll note I said "most often" and "usually" above.) The point is the direction of the reference. > these new bp "in/out" interfaces behave the same way the ddi "in/out" > interfaces do, which (to me) makes complete sense to me. > I must be confused then. Because I read the documents and came away believing that bp_copyin() copied into a buf (which could be user or kernel space) from a kernel vaddr. That's backwards from ddi_copyin, which copies from user (or kernel) space "in" to a kernel vaddr. > >> In otherwords, the "in/out" are normally used to in reference to kernel >> space. >> >> Your proposal, bp_copyin makes the "in" for this API in reference to the >> buf. (Which may or may not be userspace.) >> >> > > correct. i see no problem with this. > Again, I just find it backwards. The one part of the argument which is a fixed type of address, the kernel vaddr, is the point of reference in the ddi_copyin/copyin, but *not* in the bp_copyin. Its a switch of the point of reference that I find confusing. --Garrett > ed > > >> I find the reversal of the point of reference confusing. Does anyone else? >> >> -- Garrett >> >> Christopher Horne wrote: >> >>> I am sponsoring the following fasttrack for Mark Johnson, requesting patch >>> binding and a timeout of 10/16/2007. >>> >>> -Chris >>> >>> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >>> >>> 1. Introduction >>> 1.1 Project/Component Working Name: >>> >>> bp_copyin()/bp_copyout() >>> >>> 1.2 Name of Document Author/Supplier: >>> >>> Author: Mark Johnson >>> >>> 1.3 Date of This Document: >>> >>> Tue Oct 9 10:36:08 MDT 2007 >>> >>> 4. Technical Description >>> >>> 4.1 Introduction >>> >>> This case introduces two new buf interfaces, and is the second of >>> two fasttracks to address st tape driver performance on x86. >>> >>> dma-max-arch scsi capability >>> bp_copyin()/bp_copyout() >>> >>> There is a recently escalated bug outstanding for this issue. >>> >>> 6567168 s10 x86 st tape driver performance issue >>> http://monaco.sfbay/detail.jsf?cr=6567168 >>> >>> 4.2 Background >>> >>> Most tape drives cannot handle partial DMAs. An entire tape block >>> must be transferred in a single DMA. >>> >>> For our SPARC based systems, this is relatively simple. Since >>> these systems have an IOMMU, the only real consideration is the >>> underlying HBA's maximum DMA size, which is returned via the >>> 'dma-max' scsi capability. >>> >>> For current x86 bases systems, this becomes more complicated. Not >>> only can the maximum DMA be limited by the underlying HBA's maximum >>> DMA size, but it can also be limited by the DMA engines >>> scatter/gather list constraints (if the memory is completely >>> fragmented). >>> >>> Today on x86, the st tape driver will allocate physically >>> contiguous memory and then bp_mapin/bcopy/bp_mapout all transfers >>> where the tape blocksize is greater than 64KBytes. >>> >>> There are two parts to the solution. The first is to provide a way >>> for the st driver to query what the DMA constraints of the HBA are, >>> taking the sgllen into account. The second is to provide a 64-bit >>> optimized bp copy for block sizes which are too large to fit within >>> the HBA's sgllen constraints, but are within the HBA's maximum DMA >>> size. >>> >>> For example, the ST driver may find out that the maximum DMA >>> supported by the HBA ('dma-max') is 4M and the maximum DMA supported >>> by the HBA/system is 1M ('dma-max-arch'). The st driver can then >>> allow any blocksize <= 1M to go directly to the HBA and then use >>> the optimized copy for block sizes greater than 1M and less than or >>> equal to 4M. Today it does an un-optimized copy for block sizes >>> greater than 64K. >>> >>> This case addresses the second part of the problem. It provides two >>> new general purpose buf routines to copy data in and out of bufs. >>> These routines are supported on all architectures. >>> >>> Some implementation notes of interest. The routines will first look >>> to see if the buf has already been mapped info kernel VA space. If >>> not, they implement an optimized copy on 64-bit kernels using seg >>> kpm. >>> >>> >>> 4.3 Interface Table >>> >>> INTERFACE COMMITMENT LEVEL COMMENT >>> >>> bp_copyin(9F) Committed optimize bp_mapin, bcopy, >>> bp_copyout(9F) Committed bp_mapout. >>> >>> 4.4 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 >>> 6.6. ARC Exposure: open >>> >>> >>> >>> A.1 man page for bp_copyin(9F) >>> >>> Kernel Functions for Drivers bp_copyin(9F) >>> >>> NAME >>> bp_copyin - copy from a kernel virtual address to a buf >>> >>> SYNOPSIS >>> #include >>> #include >>> >>> int bp_copyin(caddr_t vaddr, struct buf *bp, >>> offset_t offset, size_t size); >>> >>> INTERFACE LEVEL >>> Architecture independent level 1 (DDI/DKI). >>> >>> PARAMETERS >>> vaddr Kernel virtual address to copy from. >>> >>> bp Pointer to the buffer header structure to copy to. >>> >>> offset Offset into bp where to start copying. >>> >>> size Size of copy. >>> >>> DESCRIPTION >>> bp_copyin() copies 'size' bytes starting from kernel virtual >>> address 'vaddr' to 'offset' bytes into the memory associated >>> with 'bp'. The 'offset' only applies to 'bp'. >>> >>> RETURN VALUES >>> Under normal conditions, 0 is returned to indicate a >>> successful copy. Otherwise, -1 is returned if 'bp' references >>> invalid pages. >>> >>> CONTEXT >>> bp_copyin() can be called from user or kernel context only. >>> >>> SEE ALSO >>> bp_copyout(9F), buf(9S), ddi_copyin(9F), bp_mapin(9F), >>> bp_mapout(9F). >>> >>> A.2 man page for bp_copyout(9F) >>> >>> Kernel Functions for Drivers bp_copyout(9F) >>> >>> NAME >>> bp_copyout - copy from a buf to a kernel virtual address >>> >>> SYNOPSIS >>> #include >>> #include >>> >>> int bp_copyout(struct buf *bp, caddr_t vaddr, >>> offset_t offset, size_t size); >>> >>> INTERFACE LEVEL >>> Architecture independent level 1 (DDI/DKI). >>> >>> PARAMETERS >>> bp Pointer to the buffer header structure to copy from. >>> >>> vaddr Kernel virtual address to copy to. >>> >>> offset Offset into bp where to start copying. >>> >>> size Size of copy. >>> >>> DESCRIPTION >>> bp_copyput() copies 'size' bytes starting at 'offset' bytes >>> into the memory associated with 'bp' to the destination >>> address kernel virtual address 'vaddr'. The 'offset' only >>> applies to 'bp'. >>> >>> RETURN VALUES >>> Under normal conditions, 0 is returned to indicate a >>> successful copy. Otherwise, -1 is returned if 'bp' references >>> invalid pages. >>> >>> CONTEXT >>> bp_copyout() can be called from user or kernel context only. >>> >>> SEE ALSO >>> bp_copyin(9F), buf(9S), ddi_copyout(9F), bp_mapin(9F), >>> bp_mapout(9F). >>> >>> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> From Mark.Johnson@sun.com Wed Oct 10 04:54:30 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9ABsUq0003088 for ; Wed, 10 Oct 2007 04:54:30 -0700 (PDT) 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 l9ABpFkH017393 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Oct 2007 04:51:16 -0700 (PDT) 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 <0JPP0020929G4D00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 04:51:16 -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 <0JPP00JFY29FLC30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 04:51:15 -0700 (PDT) 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 l9ABpFGv017659 for ; Wed, 10 Oct 2007 11:51:15 +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 <0JPP00D01263E800@mail-amer.sun.com> (original mail from Mark.Johnson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 05:51:15 -0600 (MDT) Received: from mrj.local ([10.7.250.203]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPP00IZ229DOC80@mail-amer.sun.com>; Wed, 10 Oct 2007 05:51:15 -0600 (MDT) Date: Wed, 10 Oct 2007 07:51:21 -0400 From: Mark Johnson Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <470CB68B.1010000@sun.com> Sender: Mark.Johnson@sun.com To: "Garrett D'Amore" Cc: Edward Pilatowicz , Christopher Horne , Chris.Horne@sun.com, Eric.Taylor@sun.com, PSARC-ext@sun.com, Randall.Ralphs@sun.com, Grant.Zhang@sun.com Message-id: <470CBCB9.7060108@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 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> <470C4E0A.3030508@sun.com> <20071010064732.GW657152@eng.sun.com> <470CB68B.1010000@sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 2448 Garrett D'Amore wrote: > Edward Pilatowicz wrote: >> On Tue, Oct 09, 2007 at 08:59:06PM -0700, Garrett D'Amore wrote: >> >>> I find the nomenclature here a bit confusing. >>> >>> ddi_copyin or copyin are most often used to copy from user space *in* to >>> kernel space. >>> >>> ddi_copyout or copyout likewise usually reference copying data *out* >>> from the kernel to user space. >>> >> >> actually, iirc this isn't correct. >> >> ddi_copyin() will copy from userland -or- the kernel into the kernel. >> ddi_copyout() will copy from the kernel to userland -or- the kernel. >> this is why drivers should use these routies vs copyin() and copyout(). >> if drivers use copyin() and copyout() and they are not layering safe >> and can not be accessed from within the kernel via the ldi. >> > > Yes, that is the "in" or the "out" is taken relative to the kernel. The > other side can be userspace, or kernel space (but is usually > userspace). (You'll note I said "most often" and "usually" above.) > The point is the direction of the reference. >> these new bp "in/out" interfaces behave the same way the ddi "in/out" >> interfaces do, which (to me) makes complete sense to me. >> > > I must be confused then. Because I read the documents and came away > believing that bp_copyin() copied into a buf (which could be user or > kernel space) from a kernel vaddr. That's backwards from ddi_copyin, > which copies from user (or kernel) space "in" to a kernel vaddr. > >> >>> In otherwords, the "in/out" are normally used to in reference to kernel >>> space. >>> >>> Your proposal, bp_copyin makes the "in" for this API in reference to the >>> buf. (Which may or may not be userspace.) >>> >>> >> >> correct. i see no problem with this. >> > > Again, I just find it backwards. The one part of the argument which is > a fixed type of address, the kernel vaddr, is the point of reference in > the ddi_copyin/copyin, but *not* in the bp_copyin. > > Its a switch of the point of reference that I find confusing. bp_copyin - copy into a buf_t bp_copyout - copy out of a buf_t I think it would be more confusing if it were the other way around. bp_ makes the reference point want to be buf_t in my mind. If your not happy with that, how about... bp_copyto - copy into a buf_t bp_copyfrom - copy out of a buf_t MRJ -- Mark Johnson Sun Microsystems, Inc. (781) 442-0869 From gdamore@sun.com Wed Oct 10 05:04:52 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9AC4p6w003201 for ; Wed, 10 Oct 2007 05:04:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9AC1U8J007899 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Oct 2007 13:01:36 +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 <0JPP002072QMQ700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 05:01:34 -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 <0JPP00JCU2QLLA40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 05:01:33 -0700 (PDT) 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 l9AC1XjV023174 for ; Wed, 10 Oct 2007 05:01:33 -0700 (PDT) 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 <0JPP00A012PUQE00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 05:01:33 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPP00C692QKCFA0@fe-sfbay-09.sun.com>; Wed, 10 Oct 2007 05:01:33 -0700 (PDT) Date: Wed, 10 Oct 2007 04:59:13 -0700 From: "Garrett D'Amore" Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <470CBCB9.7060108@sun.com> Sender: Garrett.Damore@sun.com To: Mark Johnson Cc: Edward Pilatowicz , Christopher Horne , Chris.Horne@sun.com, Eric.Taylor@sun.com, PSARC-ext@sun.com, Randall.Ralphs@sun.com, Grant.Zhang@sun.com Message-id: <470CBE91.7040306@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 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> <470C4E0A.3030508@sun.com> <20071010064732.GW657152@eng.sun.com> <470CB68B.1010000@sun.com> <470CBCB9.7060108@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 2612 Mark Johnson wrote: > > > Garrett D'Amore wrote: >> Edward Pilatowicz wrote: >>> On Tue, Oct 09, 2007 at 08:59:06PM -0700, Garrett D'Amore wrote: >>> >>>> I find the nomenclature here a bit confusing. >>>> >>>> ddi_copyin or copyin are most often used to copy from user space >>>> *in* to >>>> kernel space. >>>> >>>> ddi_copyout or copyout likewise usually reference copying data *out* >>>> from the kernel to user space. >>>> >>> >>> actually, iirc this isn't correct. >>> >>> ddi_copyin() will copy from userland -or- the kernel into the kernel. >>> ddi_copyout() will copy from the kernel to userland -or- the kernel. >>> this is why drivers should use these routies vs copyin() and copyout(). >>> if drivers use copyin() and copyout() and they are not layering safe >>> and can not be accessed from within the kernel via the ldi. >>> >> >> Yes, that is the "in" or the "out" is taken relative to the kernel. >> The other side can be userspace, or kernel space (but is usually >> userspace). (You'll note I said "most often" and "usually" above.) >> The point is the direction of the reference. >>> these new bp "in/out" interfaces behave the same way the ddi "in/out" >>> interfaces do, which (to me) makes complete sense to me. >>> >> >> I must be confused then. Because I read the documents and came away >> believing that bp_copyin() copied into a buf (which could be user or >> kernel space) from a kernel vaddr. That's backwards from ddi_copyin, >> which copies from user (or kernel) space "in" to a kernel vaddr. >> >>> >>>> In otherwords, the "in/out" are normally used to in reference to >>>> kernel >>>> space. >>>> >>>> Your proposal, bp_copyin makes the "in" for this API in reference >>>> to the >>>> buf. (Which may or may not be userspace.) >>>> >>>> >>> >>> correct. i see no problem with this. >>> >> >> Again, I just find it backwards. The one part of the argument which >> is a fixed type of address, the kernel vaddr, is the point of >> reference in the ddi_copyin/copyin, but *not* in the bp_copyin. >> >> Its a switch of the point of reference that I find confusing. > > > bp_copyin - copy into a buf_t > bp_copyout - copy out of a buf_t > > I think it would be more confusing if it were the other way > around. > > bp_ makes the reference point want to be buf_t in my mind. > > > If your not happy with that, how about... > bp_copyto - copy into a buf_t > bp_copyfrom - copy out of a buf_t That would, IMO, be better, because it doesn't overlap with the naming convention set by copyin/ddi_copyin. -- Garrett > > > > MRJ > > From Joerg.Schilling@fokus.fraunhofer.de Wed Oct 10 05:10:12 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 l9ACABdV003220 for ; Wed, 10 Oct 2007 05:10:12 -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 l9AC6d3x008331; Wed, 10 Oct 2007 20:06:48 +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 <0JPP003052Z80B00@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Oct 2007 05:06:44 -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 <0JPP00J952Z8L640@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Oct 2007 05:06:44 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9AC40n4021398; Wed, 10 Oct 2007 12:06:43 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay42i.sun.com with ESMTP id BT-MMP-1213194; Wed, 10 Oct 2007 12:06:43 +0000 (Z) Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by mms49es.sun.com with ESMTP id BT-MMP-599445; Wed, 10 Oct 2007 12:06:42 +0000 (Z) Received: from mailgw12.fraunhofer.de ([153.96.1.24] [153.96.1.24]) by relay4i.sun.com with ESMTP id BT-MMP-20871622; Wed, 10 Oct 2007 12:06:42 +0000 (Z) Received: from mailgw12.fraunhofer.de (localhost [127.0.0.1]) by mailgw12.fraunhofer.de (8.13.5+/8.13.4) with ESMTP id l9AC6fmb024619; Wed, 10 Oct 2007 14:06:41 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw12.fraunhofer.de (8.13.5+/8.13.4) with ESMTP id l9AC6c5B024539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Oct 2007 14:06:40 +0200 (CEST) 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 l9AC6bDx027426; Wed, 10 Oct 2007 14:06:37 +0200 (MEST) Received: from burner ([10.147.65.166]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 14:06:38 +0200 Date: Wed, 10 Oct 2007 14:06:33 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <470CBCB9.7060108@sun.com> To: Mark.Johnson@Sun.COM, gdamore@Sun.COM Cc: Randall.Ralphs@Sun.COM, PSARC-ext@Sun.COM, Grant.Zhang@Sun.COM, Eric.Taylor@Sun.COM, Edward.Pilatowicz@Sun.COM, cth@sac.sfbay.sun.com, Chris.Horne@Sun.COM Message-id: <470cc049.8fF+KYisLACxvSod%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.2.0.264296 X-Fraunhofer-Email-Policy: accepted References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> <470C4E0A.3030508@sun.com> <20071010064732.GW657152@eng.sun.com> <470CB68B.1010000@sun.com> <470CBCB9.7060108@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 10 Oct 2007 12:06:38.0173 (UTC) FILETIME=[02B6C0D0:01C80B36] Status: RO Content-Length: 966 Mark Johnson wrote: > > Again, I just find it backwards. The one part of the argument which is > > a fixed type of address, the kernel vaddr, is the point of reference in > > the ddi_copyin/copyin, but *not* in the bp_copyin. > > > > Its a switch of the point of reference that I find confusing. > > > bp_copyin - copy into a buf_t > bp_copyout - copy out of a buf_t > > I think it would be more confusing if it were the other way > around. Given the fact that ddi_copyin() copoies _into_ kernelspace, I wiuld expedt the same for bp_copyin(). So bp_copyin - copy into a buf_t bp_copyout - copy out of a buf_t Looks counter intuitive. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From carlsonj@phorcys.east.sun.com Wed Oct 10 05:28:09 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9ACS899003373 for ; Wed, 10 Oct 2007 05:28:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9ACOmEC028908; Wed, 10 Oct 2007 05:24:50 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPP00B133TECX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 10 Oct 2007 05:24:50 -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 <0JPP00LJ03TCFVC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 10 Oct 2007 05:24:49 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9ACOVsj010005; Wed, 10 Oct 2007 08:24:31 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9ACOVbQ010002; Wed, 10 Oct 2007 08:24:31 -0400 (EDT) Date: Wed, 10 Oct 2007 08:24:31 -0400 From: James Carlson Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <470CBE91.7040306@sun.com> To: "Garrett D'Amore" Cc: Mark Johnson , Chris.Horne@sun.com, Eric.Taylor@sun.com, PSARC-ext@sun.com, Christopher Horne , Edward Pilatowicz , Randall.Ralphs@sun.com, Grant.Zhang@sun.com Message-id: <18188.50303.575008.467654@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> <470C4E0A.3030508@sun.com> <20071010064732.GW657152@eng.sun.com> <470CB68B.1010000@sun.com> <470CBCB9.7060108@sun.com> <470CBE91.7040306@sun.com> Status: RO Content-Length: 894 Garrett D'Amore writes: > Mark Johnson wrote: > > If your not happy with that, how about... > > bp_copyto - copy into a buf_t > > bp_copyfrom - copy out of a buf_t > > That would, IMO, be better, because it doesn't overlap with the naming > convention set by copyin/ddi_copyin. It's a bit better, but the reversed sense of direction -- referring to the buf_t rather than the context of the executing thread -- still looks somewhat error-prone to me. I might have chosen something like "bp_kern2buf" and "bp_buf2kern" to make the operation clearer, if the standard copyin {to the caller} and copyout {from the caller} semantics can't be followed for some reason. -- 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 Mark.Johnson@sun.com Wed Oct 10 05:30:47 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9ACUkdc003391 for ; Wed, 10 Oct 2007 05:30:46 -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 l9ACQSV0033526 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Oct 2007 06:26:30 -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 <0JPP00B013XVOK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 05:27:31 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPP00LX03XVFVC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 05:27:31 -0700 (PDT) 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 l9ACRV3t028788 for ; Wed, 10 Oct 2007 12:27:31 +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 <0JPP00K013X1LP00@mail-amer.sun.com> (original mail from Mark.Johnson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 06:27:31 -0600 (MDT) Received: from mrj.local ([10.7.250.203]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPP007W83XOU340@mail-amer.sun.com>; Wed, 10 Oct 2007 06:27:26 -0600 (MDT) Date: Wed, 10 Oct 2007 08:27:32 -0400 From: Mark Johnson Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <18188.50303.575008.467654@gargle.gargle.HOWL> Sender: Mark.Johnson@sun.com To: James Carlson Cc: "Garrett D'Amore" , Chris.Horne@sun.com, Eric.Taylor@sun.com, PSARC-ext@sun.com, Christopher Horne , Edward Pilatowicz , Randall.Ralphs@sun.com, Grant.Zhang@sun.com Message-id: <470CC534.5070206@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 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> <470C4E0A.3030508@sun.com> <20071010064732.GW657152@eng.sun.com> <470CB68B.1010000@sun.com> <470CBCB9.7060108@sun.com> <470CBE91.7040306@sun.com> <18188.50303.575008.467654@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 916 James Carlson wrote: > Garrett D'Amore writes: >> Mark Johnson wrote: >>> If your not happy with that, how about... >>> bp_copyto - copy into a buf_t >>> bp_copyfrom - copy out of a buf_t >> That would, IMO, be better, because it doesn't overlap with the naming >> convention set by copyin/ddi_copyin. > > It's a bit better, but the reversed sense of direction -- referring to > the buf_t rather than the context of the executing thread -- still > looks somewhat error-prone to me. > > I might have chosen something like "bp_kern2buf" and "bp_buf2kern" to > make the operation clearer, if the standard copyin {to the caller} and > copyout {from the caller} semantics can't be followed for some reason. OK. I'll switch them around to match ddi_copyin() ddi_copyout() then.. Case material will be updated later today. MRJ -- Mark Johnson Sun Microsystems, Inc. (781) 442-0869 From Mark.Johnson@sun.com Wed Oct 10 05:57:04 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9ACv362003840 for ; Wed, 10 Oct 2007 05:57:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9ACrlPc029064 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Oct 2007 13:53:48 +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 <0JPP0050P55MRG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 05:53:46 -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 <0JPP00J2F55LLD70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 05:53:45 -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 l9ACrjA1000134 for ; Wed, 10 Oct 2007 12:53:45 +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 <0JPP005014YHSQ00@mail-amer.sun.com> (original mail from Mark.Johnson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Oct 2007 06:53:45 -0600 (MDT) Received: from mrj.local ([10.7.250.203]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPP005TE55DGXA0@mail-amer.sun.com>; Wed, 10 Oct 2007 06:53:39 -0600 (MDT) Date: Wed, 10 Oct 2007 08:53:45 -0400 From: Mark Johnson Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <470CC534.5070206@sun.com> Sender: Mark.Johnson@sun.com To: Mark Johnson Cc: James Carlson , "Garrett D'Amore" , Chris.Horne@sun.com, Eric.Taylor@sun.com, PSARC-ext@sun.com, Christopher Horne , Edward Pilatowicz , Randall.Ralphs@sun.com, Grant.Zhang@sun.com Message-id: <470CCB59.5010306@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 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> <470C4E0A.3030508@sun.com> <20071010064732.GW657152@eng.sun.com> <470CB68B.1010000@sun.com> <470CBCB9.7060108@sun.com> <470CBE91.7040306@sun.com> <18188.50303.575008.467654@gargle.gargle.HOWL> <470CC534.5070206@sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 2830 Mark Johnson wrote: > > James Carlson wrote: >> >> I might have chosen something like "bp_kern2buf" and "bp_buf2kern" to >> make the operation clearer, if the standard copyin {to the caller} and >> copyout {from the caller} semantics can't be followed for some reason. > > OK. I'll switch them around to match ddi_copyin() > ddi_copyout() then.. Case material will be updated > later today. Updated man pages below... Thanks, MRJ A.1 man page for bp_copyin(9F) Kernel Functions for Drivers bp_copyin(9F) NAME bp_copyin - copy from a buf(9S) into a driver buffer SYNOPSIS #include #include int bp_copyin(struct buf *bp, void *driverbuf, offset_t offset, size_t size); INTERFACE LEVEL Architecture independent level 1 (DDI/DKI). PARAMETERS bp Pointer to the buffer header structure to copy from. driverbuf Kernel virtual address to copy to. offset Offset into bp where to start copying. size Size of copy. DESCRIPTION bp_copyin() copies 'size' bytes starting at 'offset' bytes into the memory associated with 'bp' to the destination kernel virtual address 'driverbuf'. The 'offset' only applies to 'bp'. RETURN VALUES Under normal conditions, 0 is returned to indicate a successful copy. Otherwise, -1 is returned if 'bp' references invalid pages. CONTEXT bp_copyin() can be called from user or kernel context only. SEE ALSO bp_copyout(9F), buf(9S), ddi_copyout(9F), bp_mapin(9F), bp_mapout(9F). A.2 man page for bp_copyout(9F) Kernel Functions for Drivers bp_copyout(9F) NAME bp_copyout - copy from a driver buffer into a buf(9S) SYNOPSIS #include #include int bp_copyout(void *driverbuf, struct buf *bp, offset_t offset, size_t size); INTERFACE LEVEL Architecture independent level 1 (DDI/DKI). PARAMETERS driverbuf Kernel virtual address to copy from. bp Pointer to the buffer header structure to copy to. offset Offset into bp where to start copying. size Size of copy. DESCRIPTION bp_copyout() copies 'size' bytes starting from kernel virtual address 'driverbuf' to 'offset' bytes into the memory associated with 'bp'. The 'offset' only applies to 'bp'. RETURN VALUES Under normal conditions, 0 is returned to indicate a successful copy. Otherwise, -1 is returned if 'bp' references invalid pages. CONTEXT bp_copyout() can be called from user or kernel context only. SEE ALSO bp_copyin(9F), buf(9S), ddi_copyin(9F), bp_mapin(9F), bp_mapout(9F). From chris.horne@sun.com Wed Oct 10 10:48:08 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9AHm7fH016881 for ; Wed, 10 Oct 2007 10:48:07 -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 l9AHih4Y026519 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 11 Oct 2007 01:44:51 +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 <0JPP00L01IMQL000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 10 Oct 2007 10:44:50 -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 <0JPP00D5UIMPUMB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 10 Oct 2007 10:44:49 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9AHinjC016346 for ; Wed, 10 Oct 2007 17:44:49 +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 <0JPP00901HFZI000@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 10 Oct 2007 11:44:49 -0600 (MDT) Received: from sun.com ([129.150.33.166]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPP00A7VIMOE580@mail-amer.sun.com>; Wed, 10 Oct 2007 11:44:48 -0600 (MDT) Date: Wed, 10 Oct 2007 11:44:48 -0600 From: Chris Horne Subject: Re: bp_copyin()/bp_copyout() [PSARC/2007/590 FastTrack timeout 10/16/2007] In-reply-to: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> Sender: chris.horne@sun.com To: Christopher Horne Cc: PSARC-ext@sun.com, Eric.Taylor@sun.com, Grant.Zhang@sun.com, Mark.Johnson@sun.com, Randall.Ralphs@sun.com Message-id: <470D0F90.4010504@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200710092234.l99MY7lx020014@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Content-Length: 132 > 1.1 Project/Component Working Name: > > bp_copyin()/bp_copyout() This case was approved at today's PSARC meeting. -Chris