From: mouse [at] Rodents.Montreal.QC.CA (der Mouse)
Newsgroups: netbsd.tech.kern
Organization: TAC News Gateway
Date: Nov 22 2004 12:51:07
References: 1

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

> a


 >>> 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() 
only.

thanks & regards
-kamal

/~\ 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