by :We're evaluating some Sbus to VME adaptors and accessing an A24/D16
:VME card. Basically, we are squirting data in and out of VME through a
:device driver using the copyin and copyout routines. It's running on a
:Sparc 2 running the latest Sunos.
:
:However, for data transfers of any significant size, the copy routines
:seem to use 32-bit transfers which our D16 VME card doesn't handle (we
:get a bus error, correctly).
:
:Now, the documentation for uiomove (which we cannot use as we are
:using ioctl calls and not read and write) says (quoting from the
:device driver manual):
uiomove() can be used by ioctl() calls also, the only restriction is that
you should initialize the uio structure before calling uiomove().
But if uiomove() calls copyin()/copyout() (true in most of the implementations)
you will face the same problem again.
:
:"uiomove() is the most common way for device drivers to move a
:specified number of bytes between a *byte array* in kernel address
:space and an area defined by a uio structure"
:
:and
:
:"Since this routine (uiomove) uses copyin() and copyout(), the amount
:of memory that can be moved is dependant on these routines".
:
:Now this seems to me that uiomove is getting copyin and copyout to do
:a byte-by-byte transfer which would suit us fine (we just can't handle
:32-bit ones). And, indeed, the sample drivers that came with the
:adaptors use uiomove and seem to work just fine.
The move done by the copyin() copyout() routines are implementation dependent
the arguments to these routines are source, destination and count. There is
no way to force byte copying.
:
:Can anyone provide any more information on this?
:
:We can solve our problem by doing 16-bit copies via a local buffer in
:the driver and then using the copy routines but it would be nice to
:have a more elegant solution.
:
I faced a similar situation, The copyin and copyout do 32 bit copy
based on the address alignment and count. I can think of the following
solutions:
1. If you have access to the kernel code you can write your
own copy routines that does the 16 bit copy - This is a
non-standard way as this becomes machine specific.
2. Get the physical address and map the page in kernel virtual
address and do a copy - This requires that the page is not
paged(the page should be locked).
3. The way you thought of unless memory is a constraint for you
inwhich case you can think of using fubyte().
I think the use of the local buffer is a better way as it is not machine
specific.
:All comments welcome
:
:Ken
:--
:- Ken Reed, Joint European Torus, Abingdon, Oxfordshire, UK
:- Disclaimer: Please note that the above is a personal view and should not
: be construed as an official comment from the JET project.
:----------