Stopping copyout from doing 32-bit transfers

Stopping copyout from doing 32-bit transfers

Post by S Kandasa » Thu, 30 Apr 1992 03:20:06




: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.
:----------

 
 
 

1. Stopping copyout from doing 32-bit transfers

|> 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 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.
|>
|> Can anyone provide any more information on this?
I do not have SUN source but it is highly likely that they optimise copyouts
by writing byte by byte up until the first 32 bit boundary and then writing
4 byte long words as long as possible possible finishing with a couple of
single byte writes (this is what we do in our kernel which is NOT a SUN)

However looking up the doc on the onlu SBUS to VME converter that I have
(but haven't yet used) which is a BIT3 Model 466 you have to configure the
adaptor with on-voard jumpers to set both the data path size (D16 or D32)
and the address path size (A24 or A32). You didn't say which board(s)
you have but I imagine this would be a fairly standard way of doing it
(of course if you have a mix of D16 and D32 cards then you are stuck with D16
transfers).

Hope this helps,

        Mickey

PS. If (or rather) when you have things working as you wish I would be very
interested to hear about your experiences (ie choice of cards, attainable
transfer rates etc).

2. Kppp won't let you run other programs?

3. Solaris 9 installed with 32 & 64 bit supports but boots in 32 bit mode

4. playwave truncates sound?

5. 32-bit Novell desktop OS combines Unix, DOS 7

6. sftp - gftp

7. 32-bit Core files on 64-bit Sysetm

8. POLYCENTER Advanced Filesystem

9. 64-bit Solaris 7: wasn't Solaris 2.6 also 32-bit?

10. mrand48() returning 17-bit longs, instead of 32-bit

11. 64-bit to 32-bit OS change

12. REQUEST: 64-bit integer math on 32-bit processor

13. 64-bit or 32-bit?