Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261193AbVCWHN3 (ORCPT ); Wed, 23 Mar 2005 02:13:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262837AbVCWHN3 (ORCPT ); Wed, 23 Mar 2005 02:13:29 -0500 Received: from linux01.gwdg.de ([134.76.13.21]:4521 "EHLO linux01.gwdg.de") by vger.kernel.org with ESMTP id S261193AbVCWHN0 (ORCPT ); Wed, 23 Mar 2005 02:13:26 -0500 Date: Wed, 23 Mar 2005 08:13:16 +0100 (MET) From: Jan Engelhardt To: linux-os cc: Linux kernel Subject: Re: lseek on /proc/kmsg In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 859 Lines: 25 1> Sure, read() needs to be modified to respect the file-position 1> set by kmsg_seek(). I don't think you can get away with the 1> call back into do_syslog. 2>I'm not sure that seek makes any sense on that, since it is more like a 2>pipe than a normal file.. Well, seek(fd, 0, SEEK_END) could be used to flush a pipe's buffers. 0>> +static loff_t kmsg_seek(struct file *filp, loff_t offset, int origin) { 0>> + if(origin != 2 /* SEEK_END */ || offset < 0) { return -ESPIPE; } 3> "Allow" seeking past the end of the buffer? Well, what does lseek(fd, >0, SEEK_END) do on normal files? Jan Engelhardt -- - 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/