From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48703 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUJ5i-00014s-KQ for qemu-devel@nongnu.org; Thu, 01 Jul 2010 08:42:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUJ5g-0006ha-RV for qemu-devel@nongnu.org; Thu, 01 Jul 2010 08:42:06 -0400 Received: from e23smtp03.au.ibm.com ([202.81.31.145]:49823) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUJ5g-0006hH-8l for qemu-devel@nongnu.org; Thu, 01 Jul 2010 08:42:04 -0400 Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp03.au.ibm.com (8.14.4/8.13.1) with ESMTP id o61CcSJb029339 for ; Thu, 1 Jul 2010 22:38:28 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o61Cg1qq1700026 for ; Thu, 1 Jul 2010 22:42:01 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o61Cg0wP005803 for ; Thu, 1 Jul 2010 22:42:01 +1000 From: "Aneesh Kumar K. V" Subject: Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol. In-Reply-To: <20100701142613.0a5bcd3e@in.ibm.com> References: <20100528103843.4938.29265.stgit@localhost.localdomain> <87zkyb7opo.fsf@linux.vnet.ibm.com> <20100701142613.0a5bcd3e@in.ibm.com> Date: Thu, 01 Jul 2010 18:11:57 +0530 Message-ID: <87tyoj74ru.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sripathi Kodi Cc: v9fs-developer@lists.sourceforge.net, qemu-devel@nongnu.org On Thu, 1 Jul 2010 14:26:13 +0530, Sripathi Kodi wrote: > On Thu, 01 Jul 2010 11:01:15 +0530 > "Aneesh Kumar K. V" wrote: > > > On Fri, 28 May 2010 16:08:43 +0530, Sripathi Kodi wrote: > > > From: M. Mohan Kumar > > > > > > 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