Re: ``struct stat'' issue

Hello! On Sat, Nov 17, 2007 at 03:31:04PM +0100, I wrote: > On Tue, Nov 13, 2007 at 05:33:31PM -0800, Roland McGrath wrote: > > > I.e., the usec / nsec value of variable `st' (``struct stat'') isn't set > > > at all. In my reading of the used ``struct ext2_inode'' (variable `di') > > > there inde

Re: ``struct stat'' issue

Hello! On Tue, Nov 13, 2007 at 05:33:31PM -0800, Roland McGrath wrote: > > I.e., the usec / nsec value of variable `st' (``struct stat'') isn't set > > at all. In my reading of the used ``struct ext2_inode'' (variable `di') > > there indeed is nothing better than the sec value being provided. Sh

glibc patches for GNU/Hurd (was: ``struct stat'' issue)

Hello! On Fri, Nov 16, 2007 at 07:43:13PM +0100, I wrote: > Also, I'll make up a repository with all glibc patches I'm using for > GNU/Hurd. This is a mixture of stuff of mine and stuff of Debian people. I didn't verify all of that. S

Re: ``struct stat'' issue

Hello! On Tue, Nov 13, 2007 at 05:25:21PM -0800, Roland McGrath wrote: > Off hand that looks fine to me. As promised, here is the ChangeLog entry: #v+ 2007-10-05 Thomas Schwinge <[EMAIL PROTECTED]> * sysdeps/mach/hurd/bits/stat.h (struct stat): Align to what is done for Linux:

Re: ``struct stat'' issue

> I.e., the usec / nsec value of variable `st' (``struct stat'') isn't set > at all. In my reading of the used ``struct ext2_inode'' (variable `di') > there indeed is nothing better than the sec value being provided. Should > we explicitly set the usec / nsec value of `st' to zero? Yes. diskfs_

Re: ``struct stat'' issue

> On follow-up: do we want to modify all of the Hurd libraries and servers > (plus the GNU Mach maptime interface!) to also work on ``struct > timespec'' (with nanosecond resolution) instead of ``time_value_t'' (with > microsecond resolution; as it is used at the moment)? I'd leave Mach alone for

Re: ``struct stat'' issue

Off hand that looks fine to me. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: ``struct stat'' issue

Hello! On Fri, Oct 05, 2007 at 03:29:27PM +0200, I wrote: > On Sun, Jun 10, 2007 at 11:35:20PM +0200, I wrote: > > Some months ago I created some patches for the ``struct stat'' issue > > (<http://savannah.gnu.org/bugs/?18216>). Perhaps now the time has come

Re: ``struct stat'' issue

Hello! On Sun, Jun 10, 2007 at 07:49:34PM -0700, Roland McGrath wrote: > In stat.h, the pedantic-mode members need to be called nsec, not usec. > They are just another name for the struct timespec, which is ns, not us. I changed that and aligned to the Linux version. > Other stat.h changes unre

Re: ``struct stat'' issue

Thomas Schwinge, le Fri 05 Oct 2007 15:29:27 +0200, a écrit : > On follow-up: do we want to modify all of the Hurd libraries and servers > (plus the GNU Mach maptime interface!) to also work on ``struct > timespec'' (with nanosecond resolution) instead of ``time_value_t'' (with > microsecond resolu

Re: ``struct stat'' issue

Hello! On Sun, Jun 10, 2007 at 11:35:20PM +0200, I wrote: > Some months ago I created some patches for the ``struct stat'' issue > (<http://savannah.gnu.org/bugs/?18216>). Perhaps now the time has come > for someone to review them? It's been some further months n

Re: ``struct stat'' issue

That #ifdef does not belong in all those source files. It's only for the installed header. Every source file in libc and hurd will be compiled under _GNU_SOURCE. In stat.h, the pedantic-mode members need to be called nsec, not usec. They are just another name for the struct timespec, which is

Re: ``struct stat'' issue

Hi, Thomas Schwinge, le Sun 10 Jun 2007 23:35:20 +0200, a écrit : > What about the `st_?time_usec' symbols? Linux has these as `st_?timensec'. I'd say we should stick to Linux. As was discussed, making a binary move from usecs to nsecs shouldn't be a problem provided that we upgrade all users of

``struct stat'' issue

Hello! Some months ago I created some patches for the ``struct stat'' issue (<http://savannah.gnu.org/bugs/?18216>). Perhaps now the time has come for someone to review them? First follows the glibc patch, then the Hurd one. glibc patch. #v+ This patch is incomplete. R