Messages in this thread | | | Date | Sat, 19 Mar 2005 22:58:15 -0500 | From | Karim Yaghmour <> | Subject | Re: Relayfs question |
| |
Jan Engelhardt wrote: > Well, what about things like urandom? It also moves "a lot" of data and does > nothing else.
Forgive my slowness today, but I don't get the angle here: - Relayfs is not a replacement for char devices, we've never claimed it to be. - Urandom generates a lot of data, and uses copy_to_user() to get it to user-space, but it isn't a generalized buffering mechanism for transfering large amounts of data to user-space.
If what you're inquiring about is a comparison between relayfs' mechanisms and the underlying mechanisms that urandom is using, then I don't think there can be a comparison: the goals are different.
For example, urandom relies on a global spin lock and uses copy_to_user() for its transfers. This is just fine for this type of application. If you wanted to transfer a huge amount of data from the kernel to user- space (the kind of data generated by tracing facilities, for example), however, these mechanisms would be simply inadequate. If we're generating the amount of data LTT can gather, for example, (say 2MB/s as was described in the earlier thread regarding relayfs), then you need per-cpu buffering and you need to not write anything back to user-space, but dump it to disk ASAP, etc. This is where relayfs comes in handy.
On the other hand, using relayfs to replace what urandom currently uses is just the wrong thing to do. If nothing else, /dev/urandom would behave entirely differently (API, dynamics, etc.). There would also be no clear added benefit for using relayfs.
What character drivers do (mainly copy_to_user()) and what relayfs is used for are entirely different. To use a slightly exagerated example to illustrate the difference: replacing the standard mechanisms drivers use to transfer data to user-space with relayfs would be like renting a supersonic jet to get your package to a foreign country instead of just using Fedex. It works ... but it's clearly the wrong approach.
Please read relayfs.txt.
Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || karim@opersys.com || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |