>From: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
>
>maximum entropy wrote:
>
>> The leonardo read/write code is actually faulty, but for another
>> reason.  I took some shortcuts with bus space handles to generate
>> virtual addresses.  The shortcuts I took work correctly (for now) but
>> are clearly wrong because my code has no business "knowing" what these
>> handles mean.  See the recent discussion on tech-kern.
>
>Ar!  I understand why uimove() is bad.  However, I've now got more
>questions :)  Why use bus_space_read_multi_1()?  Shouldn't it use
>bus_space_read_region_1() or am I missing something else that is obvious?

It doesn't really matter which bus_space_*() function is used; the
same problems are present in any case.  The bus_space_read_region_1()
function could certainly be used to move data from the card to a
temporary buffer in kernel VM space.  A call to uiomove() could then
copy from this buffer to the user-requested target in user or kernel
space as designated in the struct uio constructed for the read call.
But this requires copying the same data twice, which is inefficient.

>And, presuambly, length could be up to the size of the memory on the card,
>so you'd want to do many read/writes to and from buf until you'd read/written
>enough.  Or, should you just define a maximum size to read/write and leave
>it up to the user process to iterate over the address space if it wants?

It would be more efficient to execute the entire requested read or
write if possible.  Artificially limiting the length would mean more
entries to the kernel from the user program, to accomplish the same
result.  Most device drivers simply compute the user-requested length,
and the actual space left until "end of device", then use the smaller
of the two as the length of the actual I/O to perform.

Cheers,
entropy

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