Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261500AbVCTDrP (ORCPT ); Sat, 19 Mar 2005 22:47:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261493AbVCTDrP (ORCPT ); Sat, 19 Mar 2005 22:47:15 -0500 Received: from opersys.com ([64.40.108.71]:37133 "EHLO www.opersys.com") by vger.kernel.org with ESMTP id S261500AbVCTDrJ (ORCPT ); Sat, 19 Mar 2005 22:47:09 -0500 Message-ID: <423CF4D7.6000706@opersys.com> Date: Sat, 19 Mar 2005 22:58:15 -0500 From: Karim Yaghmour Reply-To: karim@opersys.com Organization: Opersys inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en, fr, fr-be, fr-ca, fr-fr MIME-Version: 1.0 To: Jan Engelhardt CC: linux-kernel@vger.kernel.org Subject: Re: Relayfs question References: <423C78E8.3040200@ev-en.org> <423C913B.6000307@opersys.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2399 Lines: 50 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/