for buffer streaming which is better solution for apps to access memory buffer?
 

I am developing driver that takes data buffers and stream to user space.
so far I have gathered there is two ways to able the user to access the memory buffers.
But, I am not sure what is the best.

Here is what I found out so far:
1.using mmap() func on apps layer to read, where using vmalloc to migrate it to userspace.
I saw this example from http://www.scs.ch/~frey/linux/memorymap.html. It comes with a apps test.
In this method, it seem like the user's "see" the whole memory banks allocated. (Where I can find how to understands mmap()works? )

2. is via the copy_to user() on the kernel side. But I have not see the example how this works. also how the apps layer works. (somehow when i cat nothing pop up)

So for buffers streaming which is the more recommend method? pls advise

Take a look at chapters 3 and 15 of Linux Device Drivers, Third Edition.

From the applications point of view, using mmap() yields a normal dynamically allocated memory region, except that it is shared with your driver. All changes one makes are immediately visible to the other.

If you have a device with physical memory of its own, using mmap() to map that memory directly to userspace is extremely efficient: you can get zero-copy operation that way. Each memory access is directly seen by the hardware device.

copy_to_user() and copy_from_user() do a copy between memory allocated and used by your driver, and any client application.

The main difference between these two approaches is that using a mmap() bypasses your kernel driver. The kernel driver will not know when nor how the userspace has modified the memory.

When the data is a continuous stream of bytes, mmap() is rarely used, because it is difficult for the kernel driver to know when/if it has further data to process. (It is not impossible, however: one could use an interface similar to raw memory-mapped sockets, and use read()/write() to indicate the amount of memory prepared in the buffer, completely ignoring the data pointer. This is very nonstandard, and will confuse most application programmers, though.)

On the whole, the best answer to your question depends highly on the manner in which your driver needs to handle the data, and whether you have a related device with its own physical memory or not. If you have byte streams, mmap() is typically not the best solution -- the extra copy (copy_to_user()/copy_from_user()) is really not that expensive.

Could you give us some more details on the nature of the data you intend to process? Are they byte streams, or perhaps datagrams of known size? Do you want to minimize latencies, or maximise throughput?

If the kernel driver is just a data processor, doing some transformation on the data, you'll get better performance by writing it as a library instead.

it is a some sort of live data stream from devices.
it is streaming is bytes.

on the apps layer it suppose to streams out the bytes.
i think the closest scenario is like those audio/video streams.
i foresee there will be the needs of couple more buffers pools and sampling frames..

can you recommend a good example using copy_to_user example?(thanks ahead)
I found this http://www.freesoftwaremagazine.com/.../drivers_linux
but when I cat it...nothing appears on my terminal screen.
Not sure what I did wrong.

I see your point. I too worry on the apps site how should the apps layer handle my data.
I might refreshed my page files without knowing when the apps hv grab the latest updates.

I am new to linux..still in learning process...thanks for the reply. it helps.

How high are your bandwidth requirements? If the data rate is just dozens of megabytes per second, the "extra" copy_to_user() or copy_from_user() overhead should not matter. After all, every time you use normal file I/O, you incur that overhead anyway. Besides, a non-mmap() driver is usually simpler to write logic-wise; the concurrency issues are pretty hairy. Solvable, but hairy.

The HelloDriver at kernelnewbies.org is pretty good.

However, I do wholeheartedly recommend the LDD3, and believe it is overall the best source for information, explanations, and examples. That and Linux Kernel sources (including the Documentation/ tree) should be enough to write a working driver.

Good. It shouldn't. The driver writes to the kernel log. Check if the message appears in the kernel ring buffer (by running dmesg), or in your system logs (typically /var/log/kern.log).

Note that the LDD3 does explain all that, if you start at the first chapter.