From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: Attempt at "stat light" implementation Date: Tue, 7 Apr 2009 18:54:44 +0100 Message-ID: <20090407175444.GE31824@shareable.org> References: <20090407062356.GA1336463@fiona.linuxhacker.ru> <20090407173248.GC31824@shareable.org> <0891A741-6527-4BDE-9F6C-FD8FAA45E2F1@linuxhacker.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Oleg Drokin Return-path: Received: from mail2.shareable.org ([80.68.89.115]:58872 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755783AbZDGRyp (ORCPT ); Tue, 7 Apr 2009 13:54:45 -0400 Content-Disposition: inline In-Reply-To: <0891A741-6527-4BDE-9F6C-FD8FAA45E2F1@linuxhacker.ru> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Oleg Drokin wrote: > Hello! > Sure. When they append to sturct stat, they would add new bits. > We have 32 bits in the flags, then 3 bits are already used for AT* > flags. > That leaves us with 29 bits for STAT_* (or perhaps AT_STAT) flags, and > we already use ~15 fields in the struct stat, do we have enough bits, > or should we increase the flags width right now while we are at it? I don't see all 31 bits being used up in the foreseeable future. So it's fine as long as you (in future) make the last one __AT_STAT_MORE_FLAGS causing an additional syscall argument to be interpreted for more flags. Glibc would wrap it up. > >Once you have fine-grained selection of stat fields - it's natural to > >ask why not allow _additional_ stat fields in an future-extensible > >fashion? A few things would be handy sometimes, such as inode > >generation number, modification generation number (to detect changes > >across reboots), and extra flags indicating COW or other properties. > > >If an "extensible" attribute is not asked for, the kernel must not > >fill in that field of the structure as the app may be not have > >allocated space for it. Or it must use a tag-length-value sort of > >structure for the result, similar to network CMSGs. > > The app allocates struct stat, whatever it is, I presume. There is a > huge benefit to actually reuse existing struct stat, I believe. I agree, but you can't fill in unwanted _additional_ fields if you add any to the kernel's "struct stat" (or "struct stat_extended" which is binary compatible but has additional fields). If you do that, _old_ apps will allocate a smaller structure than the kernel is using. -- Jamie