On Tue, Oct 04, 2011 at 02:18:20PM +0530, Aneesh Kumar K.V wrote: > On Tue, 4 Oct 2011 08:18:07 +0100, Stefan Hajnoczi <stefa...@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 <stefa...@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.
Okay, then the comment should be: /* * We support handle fs driver only if futimens is provided by the host */ The scenario where it might be possible to hit the CONFIG_UTIMENSAT is with a modern kernel paired with an old userspace. The handle syscall which we call directly would succeed but the futimens(2) would not be available. On a sane system the handle syscall fails because the kernel doesn't support it (and futimens isn't there either). Stefan
