>> I don't understand what you want to do?  Do you simply want the
>> device mmap()-ed?  Why don't you do it the normal way?
> No -I do not want the device mmap()'ed by any means.  The USB device
> generates an image that could be as large as 1024x1024 bytes.  After
> doing a usbd_bulk_transfer(sc->sc_bulkin_pipe..), I want to give the
> userspace a reference to the image/data thus obtained.

If by "reference" you mean "a block of what looks to userland like
memory", this sounds like exactly the sort of thing mmap was designed
for.  Why don't you want to use it?  (I'm not saying you should.  But
your answer to this question should help me determine where my
conceptualization of your problem disagrees with yours, and thus help
find more useful comments for you.)

>> For most USB devices I would think that mmap() is a bad idea.
>> Remember that with mmap() you can read at random places in the data,
>> so if your device doesn't support this you would be forced to buffer
>> all data in the kernel.
> If the userspace has a handle, it can seek to the begining of the
> file and read from there.

This makes it sound as though you want to present the data as a file
(rather than, say, a memory segment).

Again, why?  (Similar remarks apply.)

If you have no writable mass storage media available, your only choices
are to either buffer the whole thing in memory (in which case you might
as well present it to userland with mmap(), though a file-style
interface would be fairly easy to do) or read it from the device on
demand (in which case presenting it as a file does make more sense;
this is just the sort of thing device drivers are good at: presenting
devices as if they were files).

> Yes -I am using copyout() to hand read() the reqd data.  There is an
> ioctl() that supports getting hold of the mmap()'ed filename, its
> size etc.. in the driver being ported.

You keep referring to things like this, as if there is some mmapped
file involved somewhere, but it's completely unclear to me where.  You
write of "the mmap()'ed filename", but it's not clear _what_ mmapped
file's name you're talking about.  So far, you've talked about a USB
device and a driver for it; I don't see any mmapped files anywhere in
the vicinity yet.

>> The speed of the USB 1.1 bus is low compared to the speed of a
>> copyout() on any modern platform.
> The platform is going to be an Intel Xscale processor on an embedded
> controller.  There won't be a harddisk and most likely it will be the
> cheapest such controller available in the market.  If that isn't a
> problem for using copyout(), that is great.

I'd expect it won't be a problem; I certainly wouldn't worry about it
unless copyout() proves to be too slow.  If you did present it with a
read()-style interface, you'd have to do copyout() or its moral
equivalent at *some* point to get the data from kernel to userland.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B