linux-kernel - Re: [PATCH 3/3] Add a pair of system calls to make extended file stats available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimSU_pCXW5zR8__Q3-fzgxwEUX8rPqLeZtPD_hX@mail.gmail.com>
Date:	Tue, 29 Jun 2010 15:13:04 -0700
From:	Ulrich Drepper <drepper@...il.com>
To:	David Howells <dhowells@...hat.com>
Cc:	viro@...iv.linux.org.uk, smfrench@...il.com, jlayton@...hat.com,
	mcao@...ibm.com, aneesh.kumar@...ux.vnet.ibm.com,
	linux-cifs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, samba-technical@...ts.samba.org,
	sjayaraman@...e.de, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 3/3] Add a pair of system calls to make extended file 
	stats available

On Tue, Jun 29, 2010 at 13:03, David Howells <dhowells@...hat.com> wrote:
> Add a pair of system calls to make extended file stats available, including
> file creation time, inode version and data version where available through the
> underlying filesystem:

If you add something like this you might want to integrate another
extension.  This has been discussed a long time ago.  In almost no
situation all the information is needed.  Some of the pieces of
information returned by the syscall might be harder to collect than
other.  It makes sense in such a situation to allow the caller to
specify what she is interested in.  A bitmask of some sort.  This was
brought up by the HPC people with gigantic filesystems.

For this the syscall interface should have a parameter to specify what
is requested and the stat-like structure should have a field
specifying what is actually present.  The latter bitmask must be a
superset of the former.

Previous discussions centered around reusing the stat data structure
and somehow make it work.  But no clean solution was found.  If a new
structure is added anyway this could solve the issue.

And while you're at it, maybe some spare fields at the end are nice.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/