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

[Rtp]

Eduardo Habkost <address@hidden> writes:
Hi,

> On Wed, Jun 10, 2009 at 12:06:27AM +0200, Arnaud Patard wrote:
>> Eduardo Habkost <address@hidden> writes:
>> 
>> Hi Eduardo,
>> 
>> > Some glibc versions don't have utimensat() available, but have other 
>> > xxxat()
>> > functions. Make a separated check for utimensat() to make sure we can 
>> > compile
>> > linux-user against some older glibc versions.
>> 
>> Why didn't you take the patches available in this thread
>> http://lists.gnu.org/archive/html/qemu-devel/2009-04/msg01290.html ?
>
> Because it is not included on the qemu tree.
>
>> 
>> 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 :)

>
>> 
>> [...]
>> 
>> > +#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.

> 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.

Arnaud