mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Andi Kleen <ak@suse.de>,
	eggert@twinsun.com, linux-kernel@vger.kernel.org
Subject: Re: nanosecond file timestamp resolution in filesystems, GNU make, etc.
Date: Mon, 28 Oct 2002 15:59:21 +0000	[thread overview]
Message-ID: <20021028155921.GA16929@bjl1.asuk.net> (raw)
In-Reply-To: <Pine.GSO.3.96.1021028161702.977I-100000@delta.ds2.pg.gda.pl>

Maciej W. Rozycki wrote:
> > 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.
> 
>  Hmm, I haven't thought of this argument to be used this way.  Actually it
> isn't currently initialized by glibc in any way, which makes its utility
> questionable.

You are right.  I just checked dietlibc and uclibc - neither of them
initialise the flags argument.  It should be deleted from the kernel,
because nobody can use it.

On the bright side (for my specific request of st_resolution), it
seems every architecture has a different size reserved for st_dev and
st_rdev in struct stat64:

	- i386: 12 bytes (8 bytes used by Glibc)
	- SPARC: 8 bytes (all needed for 8 byte dev_t, but space elsewhere)
	- ARM:  12 bytes
	- MIPS: 16 bytes (!)
	- S390: 12 bytes
	- Alpha: not obvious what's used - is int 64 bits wide on Alpha?
                 if it's not, other changes need for 64-bit dev_t anyway.

All the architectures I've looked at have two words available in
struct stat64, if they have struct stat64, but the available space is
in different places for each architecture.

-- Jamie


  reply	other threads:[~2002-10-28 15:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20021027153651.GB26297@pimlott.net.suse.lists.linux.kernel>
     [not found] ` <200210280947.g9S9l9H01162@sic.twinsun.com.suse.lists.linux.kernel>
2002-10-28 11:05   ` Andi Kleen
     [not found]   ` <20021028102809.GA16062@bjl1.asuk.net.suse.lists.linux.kernel>
2002-10-28 11:08     ` Andi Kleen
2002-10-28 12:56       ` Jamie Lokier
2002-10-28 14:15         ` Andi Kleen
2002-10-28 14:28           ` Maciej W. Rozycki
2002-10-28 15:13             ` Jamie Lokier
2002-10-28 15:40               ` Maciej W. Rozycki
2002-10-28 15:59                 ` Jamie Lokier [this message]
2002-10-28 15:17           ` Jamie Lokier
     [not found] <20021027153651.GB26297@pimlott.net>
2002-10-28  9:47 ` Paul Eggert
2002-10-28 10:28   ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021028155921.GA16929@bjl1.asuk.net \
    --to=lk@tantalophile.demon.co.uk \
    --cc=ak@suse.de \
    --cc=eggert@twinsun.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@ds2.pg.gda.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®