Re: [Qemu-devel] buildbot failure in qemu on default_x86_64_rhel5

["Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>]

On Tue, 4 Oct 2011 08:18:07 +0100, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Mon, Oct 03, 2011 at 04:10:50PM +0530, Aneesh Kumar K.V wrote:
> > On Mon, 3 Oct 2011 08:37:52 +0100, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > > On Sat, Oct 01, 2011 at 03:03:23PM +0530, Aneesh Kumar K.V wrote:
> > > > +#ifndef CONFIG_UTIMENSAT
> > > > +    /*
> > > > +     * We support handle fs driver only if all related
> > > > +     * syscalls are provided by host.
> > > > +     */
> > > 
> > > Perhaps a ./configure check should be added to see whether the handle
> > > syscalls are supported instead of using CONFIG_UTIMENSAT.
> > > 
> > 
> > We already do check for handle syscall. Since glibc doesn't have the
> > this syscall yet, I added the check in virtio-9p-handle.c as below
> 
> CONFIG_UTIMENSAT is defined when the host has glibc >= 2.6.
> 
> Handle syscalls are available on Linux 2.6.39 but not exposed by glibc.
> 
> Therefore CONFIG_UTIMENSAT has nothing to do with handle syscalls and
> does not mean handle syscalls are supported.  I would drop that hunk of
> the patch or test for the actual handle syscalls in ./configure.

Here is what i am trying to achieve with the patch. For handle based fs
driver to work we need to have 

1) support for handle syscall
2) support for fd based syscalls like futimens, fstatat, readlinkat,
fchmod, fchownat, openat etc.

Now handle syscalls are recently added to kernel and glibc doesn't have
support for that. So what we did is to add handle syscall in
virtio-9p-handle.c via syscall(2). Now if the syscall is not supported
by the host kernel we will get ENOSYS. I only added support for i386 and
x86_64, because most the syscall number varies with different archs. For
other archs the wrapper returns ENOSYS. So instead of checking for
handle syscalls in configure script we did the above to make sure it
work without failure in most of the case. Once we have glibc support for
handle syscall the above changes should be dropped in favor of
configure script test.

Now for the fd based syscall dependency, we didn't initially had any
check for that because my expectation was most glibc should
have support for them. But RHEL 5 build failure indicate that futimens
is not supported. We were already checking for futimens in configure so
i added changes to make sure if futimens is not supported
handle_utimensat returns error. (That was not added as a run time
check, but rather a compile error fix). Now should we allow handle based fs
driver if futimens is not supported. I was suggesting we should not;
hence the check in init to return error when we don't support
futimens. The later part of init routine do check whether handle
syscalls are supported and disable handle fs driver if they are not.


-aneesh