Re: [Qemu-devel] [PATCH 2/2] check for utimensat() availability on configure

[Eduardo Habkost]

Excerpts from Arnaud Patard (Rtp)'s message of Wed Jun 10 11:39:25 -0300 2009:
> Eduardo Habkost <address@hidden> writes:
<snip>
> >> 
> >> afaik, they can also be found in maemo's qemu git tree (and sent again
> >> later to the mailing list)
> >
> > Why is it not included, if it is a better fix?
> 
> I don't have the reason, only guesses. It looks like linux-user is
> getting a lot less attention than full system emulation, which makes
> patches living in the mailing list waiting for someone to merge them. I
> hope I'm wrong on that and that such fixes will be committed soon :)

I hope so.  :)

> 
> >
> >> 
> >> [...]
> >> 
> >> > +#ifdef CONFIG_UTIMENSAT
> >> > +
> >> > +#ifdef TARGET_NR_utimensat
> >> > +static int sys_utimensat(int dirfd, const char *pathname,
> >> > +    const struct timespec times[2], int flags)
> >> > +{
> >> > +  return (utimensat(dirfd, pathname, times, flags));
> >> > +}
> >> 
> >> As you'll see when reading the thread I mentionned, this is broken.
> >
> > I don't see why it is broken, unless current qemu code is broken
> > too. I
> 
> current qemu code is broken too.

Now this makes sense.

> 
> > just changed it to use the !CONFIG_ATFILE sys_utimensat() implementation
> > (that was already present on the code) if glibc doesn't provide
> > utimensat(). What do you suggest instead?
> 
> glibc utimensat is not exactly the syscall, a test on some parameters
> has been added. There's code to handle this in the patch I was talking
> about.

Understood. However, my patch addresses a different issue, that is the
case where the host system doesn't have utimensat() available. The point
here is to disable the code that uses utimensat() (be it broken or not)
on that case.

And the first patch is unrelated to that question: it is just a
correctness issue to make sure the xxxat() availability matches the
situation detected by ./configure (whose test code has #define
_ATFILE_SOURCE).
-- 
Eduardo