All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
To: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: v9fs-developer@lists.sourceforge.net,
	Sripathi Kodi <sripathik@in.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [V9fs-developer] [PATCH] virtio-9p: getattr server implementation for 9P2000.L protocol.
Date: Fri, 04 Jun 2010 07:59:42 -0700	[thread overview]
Message-ID: <4C0914DE.3050800@linux.vnet.ibm.com> (raw)
In-Reply-To: <87r5kntd54.fsf@linux.vnet.ibm.com>

Aneesh Kumar K. V wrote:
> On Thu, 3 Jun 2010 18:29:02 +0530, Sripathi Kodi <sripathik@in.ibm.com> wrote:
>> On Wed, 02 Jun 2010 19:49:24 +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
>>>
>>> So it should be scaled by iounit right ? If we say 9p block size is iounit.
>> Yes, I think it should be iounit. Currently st_blksize being returned
>> in stat structure to the user space does not use this field that comes
>> from the server. It is being calculated as follows in
>> generic_fillattr():
>>
>>         stat->blksize = (1 << inode->i_blkbits);
>>
>> So there may not be a need to put st_blksize on the protocol. Further,
>> inode->i_blkbits is copied from sb->s_blocksize_bits. For 9P this value
>> is obtained as:
> 
> That is what linux kernel currently does. But from the protocol point of
> view and not looking at specific linux implementation i would suggest to
> put st_blksize on wire. 

This is part of .L protocol. Specifically for Linux systems. So, if Linux is already
doing it, I don't think we need to repeat it.

Thanks,
JV

> 
> 
> -aneesh
> 

  reply	other threads:[~2010-06-04 14:59 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) [this message]
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
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=4C0914DE.3050800@linux.vnet.ibm.com \
    --to=jvrao@linux.vnet.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sripathik@in.ibm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.