Date: Mon, 17 Nov 2003 00:30:07 -0800
From: William Lee Irwin III <wli@holomorphy.com>
To: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Cc: viro@parcelfarce.linux.theplanet.co.uk, linux-kernel@vger.kernel.org
Subject: Re: seq_file and exporting dynamically allocated data
Message-ID: <20031117083007.GA22764@holomorphy.com>
Mail-Followup-To: William Lee Irwin III <wli@holomorphy.com>,
	Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-kernel@vger.kernel.org
References: <20031117054820.GT24159@parcelfarce.linux.theplanet.co.uk> <Pine.LNX.4.44.0311170745170.1089-100000@einstein.homenet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0311170745170.1089-100000@einstein.homenet>
Organization: The Domain of Holomorphy
User-Agent: Mutt/1.5.4i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1013
Lines: 21

On Mon, Nov 17, 2003 at 08:21:34AM +0000, Tigran Aivazian wrote:
> Now, since there is no way to detect EOF, other than by reading an extra 
> page and discovering that it belongs to the next iteration, we have to do 
> the lseek(fd, 0, SEEK_SET) anyway.
> So, the "auto-rewinding" read would only help the cases where application 
> doesn't need to differentiate between samples and is happy to just 
> continuously read chunks packed into pages one by one as fast as 
> possible. In this case it doesn't need to lseek to 0, so auto-rewinding on 
> kernel side would prevent it from slowing down.

If you're going to repeatedly read from 0 pread() sounds like a good
alternative to read() + lseek(), plus no kernel changes required to
get rid of the lseek().


-- wli
-
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/