Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 28 Oct 2002 10:08:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 28 Oct 2002 10:07:34 -0500 Received: from bjl1.asuk.net.64.29.81.in-addr.arpa ([81.29.64.88]:60069 "EHLO bjl1.asuk.net") by vger.kernel.org with ESMTP id ; Mon, 28 Oct 2002 10:06:56 -0500 Date: Mon, 28 Oct 2002 15:13:09 +0000 From: Jamie Lokier To: "Maciej W. Rozycki" Cc: Andi Kleen , eggert@twinsun.com, linux-kernel@vger.kernel.org Subject: Re: nanosecond file timestamp resolution in filesystems, GNU make, etc. Message-ID: <20021028151309.GB16546@bjl1.asuk.net> References: <20021028151533.D18441@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 969 Lines: 23 Maciej W. Rozycki wrote: > > It's impossible. There is no space left in struct stat64 > > And adding a new syscall just for that would be severe overkill. > > Well, possibly more stuff could benefit from new stat syscalls, like a > st_gen member for inode generations. And as someone suggested, a version > number or a length could be specified by the calls this time to permit > less disturbing expansion in the future. It's already there. The kernel stat64() syscall has a flags argument, which is unused at the moment. I presume it's for this purpose. Glibc aleady uses a version number for its stat() calls, to permit binary compatible extensions on the user side. So all the mechanism is there AFAIK. -- Jamie - 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/