qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2] i_generation / st_gen support for handle ba


From: Aneesh Kumar K.V
Subject: Re: [Qemu-devel] [PATCH 2/2] i_generation / st_gen support for handle based fs driver
Date: Fri, 05 Aug 2011 00:15:06 +0530
User-agent: Notmuch/0.5-318-g52e4ded (http://notmuchmail.org) Emacs/23.2.1 (x86_64-pc-linux-gnu)

On Thu, 4 Aug 2011 15:31:08 +0100, Stefan Hajnoczi <address@hidden> wrote:
> On Thu, Aug 4, 2011 at 1:03 PM, Aneesh Kumar K.V
> <address@hidden> wrote:
> > On Thu, 4 Aug 2011 12:47:42 +0100, Stefan Hajnoczi <address@hidden> wrote:
> >> On Thu, Aug 4, 2011 at 12:20 PM, Aneesh Kumar K.V
> >> <address@hidden> wrote:
> >> > On Thu, 4 Aug 2011 11:21:05 +0100, Stefan Hajnoczi <address@hidden> 
> >> > wrote:
> >> >> On Thu, Aug 4, 2011 at 11:06 AM, Harsh Prateek Bora
> >> >> <address@hidden> wrote:
> >> >> > This patch provides support for st_gen for handle based fs type 
> >> >> > server.
> >> >> > Currently the support is provided for ext4, btrfs, reiserfs and xfs.
> >> >> >
> >> >> > Signed-off-by: Harsh Prateek Bora <address@hidden>
> >> >> > ---
> >> >> >  hw/9pfs/virtio-9p-handle.c |   30 ++++++++++++++++++++++++++++++
> >> >> >  1 files changed, 30 insertions(+), 0 deletions(-)
> >> >>
> >> >> Does handle-based file I/O really need to duplicate all this code?  Is
> >> >> it possible to use either regular open or handle-based open from a
> >> >> single local fs codebase?
> >> >
> >> > The only details common between handle based and local based getversion
> >> > callback is the ioctl. Moving that into a helper may not really help in
> >> > this case ?.
> >>
> >> Aneesh, do you have a public virtfs tree that I can look at?  In
> >> qemu.git we don't have virtio-9p-handle.c yet, so I can't give any
> >> specific feedback.
> >
> > http://repo.or.cz/w/qemu/v9fs.git for-upstream
> >
> > I should send the patchset to qemu list soon. Was waiting for the
> > co-routine patches to go upstream.
> 
> The handle code looks like a copy of the local backend minus security
> models.  It just needs to use handle syscalls instead of using paths.
> 
> If you treat the path as the "handle" and use regular openat(2), then
> the handle code could do what the local backend does today.  Except
> compared to the local backend it would not have security models and be
> a bit slower due to extra syscalls.
> 
> Is the plan to add security models to the handle backend?  If so, then
> handle and local will be equivalent and duplicate code.
>

handle require root user privileges to run. So security model with
handle fs driver doesn't make sense. We added mapped security model to
avoid requiring user to run as root.

-aneesh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]