Subject: Re: mmap() from kernel to user
To: None <email@example.com>
From: Kamal R. Prasad <firstname.lastname@example.org>
Date: 11/22/2004 21:46:45
From: mouse [at] Rodents.Montreal.QC.CA (der Mouse)
Organization: TAC News Gateway
Date: Nov 22 2004 12:51:07
>>> 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.)
Yes -I do want to use mmap(). Since driver and userland library are in
different address spaces, I do not know how to give userland ref to the
block of memory. The only way I am aware of is to give the filename of
the mmap()'ed file i.e. not using anon_map, but that would mean using
the filesystem -which I want to avoid.
>>> 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
The original driver in WinCE uses memory mapped files. It presumes that
there will be C:\ drive and it will be used on windows CE -none of
which is going to be true. The embedded controller will come without a
hard disk -and we won't be buying winCE licenses.
Im tryig to port the driver, and was trying to skip using the filesystem.
>(rather than, say, a memory segment).
How would I do that i.e. hand userspace a memory segment?
>Again, why? (Similar remarks apply.)
Just herd-mentality I guess. The hw vendor thinks copyout() is not good
enough and he needs to pass a ref. to the block -and I was trying to
adhere to it within my constraints.
>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
How? I know I can do it with shared memory because there is a shmid, but
not aware of being able to do it with anon_map. BTW -any way I can use
shared memory across user/kernel land?
>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).
The driver in WinCE has an IOCTL_GET_FILEName which the userland will
use to access the data.
>> 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.
I was referring to the ioctl in WinCE for which I want to provide
>>> 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.
Yeah -but the WinCE driver provides more than one way of reading the
data i.e. a read() which does involve a copyout() and an ioctl() which
doesn't. I have access to the userland library src code which interfaces
with the driver -so worst case, I will bypass the ioctl() and use read()
thanks & regards
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse [at] rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B