qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Sripathi Kodi <sripathik@in.ibm.com>
To: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: v9fs-developer@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol.
Date: Thu, 1 Jul 2010 14:26:13 +0530	[thread overview]
Message-ID: <20100701142613.0a5bcd3e@in.ibm.com> (raw)
In-Reply-To: <87zkyb7opo.fsf@linux.vnet.ibm.com>

On Thu, 01 Jul 2010 11:01:15 +0530
"Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> On Fri, 28 May 2010 16:08:43 +0530, Sripathi Kodi <sripathik@in.ibm.com> wrote:
> > From: M. Mohan Kumar <mohan@in.ibm.com>
> > 
> > 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.

Thanks,
Sripathi.

> -aneesh
> 

  reply	other threads:[~2010-07-01  8:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-28 10:38 [Qemu-devel] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol Sripathi Kodi
2010-06-02 14:19 ` [Qemu-devel] Re: [V9fs-developer] " Aneesh Kumar K. V
2010-06-03 12:59   ` Sripathi Kodi
2010-06-04  8:28     ` Aneesh Kumar K. V
2010-06-04 14:59       ` Venkateswararao Jujjuri (JV)
2010-06-05 13:41         ` Aneesh Kumar K. V
2010-06-07 10:34           ` Sripathi Kodi
2010-06-07 12:28             ` [V9fs-developer] [Qemu-devel] " Sripathi Kodi
2010-07-01  5:31 ` [Qemu-devel] Re: [V9fs-developer] " Aneesh Kumar K. V
2010-07-01  8:56   ` Sripathi Kodi [this message]
2010-07-01 12:41     ` Aneesh Kumar K. V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100701142613.0a5bcd3e@in.ibm.com \
    --to=sripathik@in.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).