Subject: Re: mmap() from kernel to user
To: None <firstname.lastname@example.org>
From: Kamal R. Prasad <email@example.com>
Date: 11/22/2004 18:04:12
I am not subscribed tp tech-kern, so am cut-pasting stuff.
*From:* lennart [at] augustsson.net
<mailto:lennart%20%5Bat%5D%20augustsson.net> (Lennart Augustsson)
*Organization:* TAC News Gateway
*Date:* Nov 22 2004 07:25:55
>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.
>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.
But 1 of the reasons why I wanted to use mmap() is that the hw vendor gave a windows (CE) driver src that does
about the same -and I presumed he must be trying to optimize with good reasons.
>Why don't you want to use copyout()?
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.
>The speed of the USB 1.1 bus is low compared to the speed of a copyout() on any modern
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.
>The device can never overwhelm the system with data. A device
>is only allowed to send when asked to do so.
So as I understand the device will probably be built to ensure that when there is a delay between data acquisition and
a call to usbd_bulk_transfer(...), no data will be lost.
> -- Lennart