>From: Leo Weppelman <leo@wau.mis.ah.nl>
>On Wed 17 Dec 1997, Jason Thorpe wrote:
>>  Leo Weppelman <leo@wau.mis.ah.nl> wrote:
>> 
>>  > Yesterday, I was looking at a contributed driver that contained a line
>>  > like:
>>  > 
>>  >      uiomove((caddr_t)(sc->sc_memt + sc->sc_memh + uio->uio_offset),
>>  >              length, uio);
>>  > 
>>  > obviously, this is not correct. However, what *is* the correct solution
>>  > here? Should there always be an intermediate copy to a buffer like:
>>  >      bus_space_read_multi_1(sc->sc_memt, sc->sc_memh, uio->uio_offset,
>>  >                             buf, length);
>>  >      uiomove(buf, length, uio);
>>  > 
>>  > This is not very efficient.  Am I missing something obvious?
>> 
>> What is the driver?  In any case, with shared memory devices like this,
>> you really don't have much of a choice.
>
>It is a driver for a Leonardo VME graphics card. The framebuffer maps
>into VME memory. The read/write functions used the uiomove().
>
>I was more or less hoping I missed something. That extra copy bothers
>me.

I don't think the performance hit of the extra copy is too big a deal
in this case.  The read/write interface in this driver was mostly a
convenience for testing (i.e. so I could dd an image to/from the
framebuffer without writing code to map the device and copy the image)
and was left in only for completeness's sake.  In practice I'm really
only using the mmap() interface.

I agree that a portable way to do the IO without the extra copy would
be a win in general.  However a bus-spaceified version of uiomove()
doesn't look trivial at first glance, because of copyin() and
copyout() which are MD.

I wrote this driver primarily for the learning experience, so I'm
quite interested to hear what Those Of You Who Know The Right Thing To
Do think about this problem, and whether a real solution is possible.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.