[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server
From: |
Aneesh Kumar K. V |
Subject: |
Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol. |
Date: |
Thu, 01 Jul 2010 18:11:57 +0530 |
User-agent: |
Notmuch/ (http://notmuchmail.org) Emacs/24.0.50.1 (i686-pc-linux-gnu) |
On Thu, 1 Jul 2010 14:26:13 +0530, Sripathi Kodi <address@hidden> wrote:
> On Thu, 01 Jul 2010 11:01:15 +0530
> "Aneesh Kumar K. V" <address@hidden> wrote:
>
> > On Fri, 28 May 2010 16:08:43 +0530, Sripathi Kodi <address@hidden> wrote:
> > > From: M. Mohan Kumar <address@hidden>
> > >
> > > SYNOPSIS
> > >
> > > size[4] Tgetattr tag[2] fid[4]
> > >
> > > size[4] Rgetattr tag[2] lstat[n]
> > >
> > > DESCRIPTION
> > >
> > > The getattr transaction inquires about the file identified by fid.
> > > The reply will contain a machine-independent directory entry,
> > > laid out as follows:
> > >
> > > qid.type[1]
> > > the type of the file (directory, etc.), represented as a bit
> > > vector corresponding to the high 8 bits of the file's mode
> > > word.
> > >
> > > qid.vers[4]
> > > version number for given path
> > >
> > > qid.path[8]
> > > the file server's unique identification for the file
> > >
> > > st_mode[4]
> > > Permission and flags
> > >
> > > st_nlink[8]
> > > Number of hard links
> > >
> > > st_uid[4]
> > > User id of owner
> > >
> > > st_gid[4]
> > > Group ID of owner
> > >
> > > st_rdev[8]
> > > Device ID (if special file)
> > >
> > > st_size[8]
> > > Size, in bytes
> > >
> > > st_blksize[8]
> > > Block size for file system IO
> > >
> > > st_blocks[8]
> > > Number of file system blocks allocated
> > >
> > > st_atime_sec[8]
> > > Time of last access, seconds
> > >
> > > st_atime_nsec[8]
> > > Time of last access, nanoseconds
> > >
> > > st_mtime_sec[8]
> > > Time of last modification, seconds
> > >
> > > st_mtime_nsec[8]
> > > Time of last modification, nanoseconds
> > >
> > > st_ctime_sec[8]
> > > Time of last status change, seconds
> > >
> > > st_ctime_nsec[8]
> > > Time of last status change, nanoseconds
> > >
> > >
> > > This patch implements the client side of getattr implementation for
> > > 9P2000.L.
> > > It introduces a new structure p9_stat_dotl for getting Linux stat
> > > information
> > > along with QID. The data layout is similar to stat structure in Linux user
> > > space with the following major differences:
> > >
> > > inode (st_ino) is not part of data. Instead qid is.
> > >
> > > device (st_dev) is not part of data because this doesn't make sense on the
> > > client.
> > >
> > > All time variables are 64 bit wide on the wire. The kernel seems to use
> > > 32 bit variables for these variables. However, some of the architectures
> > > have used 64 bit variables and glibc exposes 64 bit variables to user
> > > space on some architectures. Hence to be on the safer side we have made
> > > these 64 bit in the protocol. Refer to the comments in
> > > include/asm-generic/stat.h
> > >
> > >
> >
> > Can we just hold on this patch. There is a discussion to add
> > i_generation and inode create time to a variant of stat. So may be the
> > protocol bits need those
> >
>
> IMHO, we can put this in now and change it later if needed based on how
> the discussion about VFS changes go because:
> a) 9P2000.L is still at experimental stage, so it allows us to change
> the protocol later.
> b) The kernel patch for this is already in linux-next. Without these
> patches in QEMU it won't be possible to use 9P2000.L.
>
The comment was w.r.t kernel and qemu patches. I am not sure whether we
would reach a conclusion about how the syscall interface soon. But i
guess BSD already support birth time. So in any way having a protocol
update to support i_generation and birth time is a good thing to do,
because we already know that NFS and CIFS would need it from a file system.
-aneesh