From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:54934)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RJKug-0004Te-Mx
	for qemu-devel@nongnu.org; Thu, 27 Oct 2011 04:02:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RJKuf-00063z-8c
	for qemu-devel@nongnu.org; Thu, 27 Oct 2011 04:02:10 -0400
Received: from mx1.redhat.com ([209.132.183.28]:1025)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RJKue-00063i-PB
	for qemu-devel@nongnu.org; Thu, 27 Oct 2011 04:02:09 -0400
Message-ID: <4EA910B6.5050502@redhat.com>
Date: Thu, 27 Oct 2011 10:05:10 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <CAOuPNLhf9HsyZ0_1Hnsm6_R9iEzUxd7okcTyGU2XyfjmGBsKew@mail.gmail.com>
	<4E983931.2070009@redhat.com>
	<CAOuPNLj1eA=qDtVQt9REa9+eP2466Xz4OnKuk8T=XBF-1nUkbQ@mail.gmail.com>
	<4E984347.9030804@redhat.com>
	<CAOuPNLgzjFbRWeJBz7T-WQtwkt2PyEwiVeop+aMCepojg9hyfw@mail.gmail.com>
	<CAOuPNLiK2kNbJ6NbrHXxVkqDmRYyfTHoapAFTU_8O=sjyMU1uw@mail.gmail.com>
	<CAOuPNLgxW0J3UA8tBg5i_niKMKnnM+G6fsKAYamj7RBDKCxxww@mail.gmail.com>
	<alpine.DEB.1.00.1110151406060.3778@bonsai2>
	<CAOuPNLincTb=rdqqRopdoyWESBZ7AHnn8KoC2rN3eTPi6P4sSA@mail.gmail.com>
	<alpine.DEB.1.00.1110181504170.32316@s15462909.onlinehome-server.info>
	<CAOuPNLgAyqwgmhEY1-L=jkkcov8hUsuYmRikUxPAmKEPp8Y_=Q@mail.gmail.com>
	<CAOuPNLjN2Gkrn8ZxD+40M9qOpexbxcNmkKtEPqh=Em9ujeJ_Bw@mail.gmail.com>
	<4E9FD811.6050002@redhat.com>
	<CAOuPNLgZp+YgFAL+=WTyJhZz=HfSEp-pCZ6DN1E4Sw04iRP9yw@mail.gmail.com>
	<alpine.DEB.1.00.1110221345330.1930@bonsai2>
	<CAOuPNLg=YpQApdVhUQHmG0gk4j54e=FR6wji3rKdnzueq_y1RQ@mail.gmail.com>
In-Reply-To: <CAOuPNLg=YpQApdVhUQHmG0gk4j54e=FR6wji3rKdnzueq_y1RQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for
	understanding/modification
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Pintu Kumar <pintu.ping@gmail.com>
Cc: qemu-devel@nongnu.org, Johannes Schindelin <Johannes.Schindelin@gmx.de>

Am 26.10.2011 21:17, schrieb Pintu Kumar:
> Dear Mr. Johannes,
> 
> I am sorry but I think you took me wrong. I never asked you to do things for me.
> I just wanted few clarifications to proceed further as I was stuck
> after performing few experiments as below:

You are stuck because you still didn't think about the theory before
jumping to the code. Please do this before asking more questions. Both
Johannes and I have told you that it's not as easy as you seem to think.

When you have a design to solve the problem (and I believe it might be
better to start that from scratch rather than extending vvfat as it
would end up being a rewrite anyway), we can discuss that design. But it
doesn't make any sense to discuss detailed changes in vvfat when you
don't even seem to understand the problem.

> But there is one problem here if I use the above logic.
> When I issue "ls" command "vvfat_read" is not getting triggered.
> So I think there is some problem and I could figure out where to
> implement the dynamic scanning of sub-directory later.

Why do you expect that vvfat_read is called? If the guest OS has the
directory entries already cached, there's no reason for it to read them
from disk.

Kevin