Subject: Re: mmap() from kernel to user
To: None <tech-kern@netbsd.org>
From: Kamal R. Prasad <kamalp@acm.org>
List: tech-kern
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)
*Newsgroups:* netbsd.tech.kern
*Organization:* TAC News Gateway
*Date:* Nov 22 2004 07:25:55
*References:* 1 
<http://news.gw.com/netbsd.tech.kern/%3C41A0F4E4.9090202%40acm.org%3E>

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

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

regards
-kamal

>	-- Lennart