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 <sys/types.h>
>>> #include <sys/buf.h>
>>>
>>> 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 <sys/types.h>
>>> #include <sys/buf.h>
>>>
>>> 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 at opensolaris.org
>>
