All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>,
	Christian Schoenebeck <qemu_oss@crudebyte.com>
Subject: Re: [PATCH v2 4/9] tests/virtio-9p: added readdir test
Date: Tue, 07 Jan 2020 13:25:46 +0100	[thread overview]
Message-ID: <10962452.xo9bJ14PLm@silver> (raw)
In-Reply-To: <20200106182252.58dd6712@bahia.lan>

On Montag, 6. Januar 2020 18:22:52 CET Greg Kurz wrote:
> > diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
> > index 06263edb53..48c0eca292 100644
> > --- a/tests/virtio-9p-test.c
> > +++ b/tests/virtio-9p-test.c
> > @@ -68,6 +68,11 @@ static void v9fs_memread(P9Req *req, void *addr, size_t
> > len)> 
> >      req->r_off += len;
> >  
> >  }
> > 
> > +static void v9fs_uint8_read(P9Req *req, uint8_t *val)
> > +{
> > +    v9fs_memread(req, val, 1);
> > +}
> > +
> > 
> >  static void v9fs_uint16_write(P9Req *req, uint16_t val)
> >  {
> >  
> >      uint16_t le_val = cpu_to_le16(val);
> > 
> > @@ -101,6 +106,12 @@ static void v9fs_uint32_read(P9Req *req, uint32_t
> > *val)> 
> >      le32_to_cpus(val);
> >  
> >  }
> > 
> > +static void v9fs_uint64_read(P9Req *req, uint64_t *val)
> > +{
> > +    v9fs_memread(req, val, 8);
> > +    le64_to_cpus(val);
> > +}
> > +
> > 
> >  /* len[2] string[len] */
> >  static uint16_t v9fs_string_size(const char *string)
> >  {
> > 
> > @@ -191,6 +202,7 @@ static const char *rmessage_name(uint8_t id)
> > 
> >          id == P9_RLOPEN ? "RLOPEN" :
> >          id == P9_RWRITE ? "RWRITE" :
> > 
> >          id == P9_RFLUSH ? "RFLUSH" :
> > +        id == P9_RREADDIR ? "READDIR" :
> >          "<unknown>";
> >  
> >  }
> > 
> > @@ -348,6 +360,79 @@ static void v9fs_rwalk(P9Req *req, uint16_t *nwqid,
> > v9fs_qid **wqid)> 
> >      v9fs_req_free(req);
> >  
> >  }
> > 
> > +/* size[4] Treaddir tag[2] fid[4] offset[8] count[4] */
> > +static P9Req *v9fs_treaddir(QVirtio9P *v9p, uint32_t fid, uint64_t
> > offset,
> > +                            uint32_t count, uint16_t tag)
> > +{
> > +    P9Req *req;
> > +
> > +    req = v9fs_req_init(v9p, 4 + 8 + 4, P9_TREADDIR, tag);
> > +    v9fs_uint32_write(req, fid);
> > +    v9fs_uint64_write(req, offset);
> > +    v9fs_uint32_write(req, count);
> > +    v9fs_req_send(req);
> > +    return req;
> > +}
> > +
> > +struct v9fs_dirent {
> 
> The QEMU coding style calls for a CamelCase typedef,
> 
> ie.
> 
> typedef struct V9fsDirent V9fsDirent;

np

> > +    v9fs_qid qid;
> 
> Yeah... I should have done the same when I introduced this type ;-)

So I'll probably address your sin with a separate patch then.

> > +static void fs_readdir(void *obj, void *data, QGuestAllocator *t_alloc)
> > +{
> > +    QVirtio9P *v9p = obj;
> > +    alloc = t_alloc;
> > +    char *const wnames[] = { g_strdup(QTEST_V9FS_SYNTH_READDIR_DIR) };
> > +    uint16_t nqid;
> > +    v9fs_qid qid;
> > +    uint32_t count, nentries;
> > +    struct v9fs_dirent *entries = NULL;
> > +    P9Req *req;
> > +
> > +    fs_attach(v9p, NULL, t_alloc);
> > +    req = v9fs_twalk(v9p, 0, 1, 1, wnames, 0);
> > +    v9fs_req_wait_for_reply(req, NULL);
> > +    v9fs_rwalk(req, &nqid, NULL);
> > +    g_assert_cmpint(nqid, ==, 1);
> > +
> > +    req = v9fs_tlopen(v9p, 1, O_DIRECTORY, 0);
> > +    v9fs_req_wait_for_reply(req, NULL);
> > +    v9fs_rlopen(req, &qid, NULL);
> > +
> > +    req = v9fs_treaddir(v9p, 1, 0, P9_MAX_SIZE - P9_IOHDRSZ, 0);
> > +    v9fs_req_wait_for_reply(req, NULL);
> > +    v9fs_rreaddir(req, &count, &nentries, &entries);
> > +
> > +    /*
> > +     * Assuming msize (P9_MAX_SIZE) is large enough so we can retrieve
> > all
> > +     * dir entries with only one readdir request.
> > +     */
> > +    g_assert_cmpint(
> > +        nentries, ==,
> > +        QTEST_V9FS_SYNTH_READDIR_NFILES + 2 /* "." and ".." */
> > +    );
> 
> What about coming up with a version of this test that loops until
> it could read all the entries instead of this assumption ?

Yes, I had this planned a bit later though. And not as a replacement for this 
one, but rather as a subsequent advanced readdir test. Because it makes sense 
to cover both cases: readdir a large amount of entries with a single request, 
but also splitted down by several readdir requests as subsequent, separate 
test.

Best regards,
Christian Schoenebeck




  reply	other threads:[~2020-01-07 12:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 14:17 [PATCH v2 0/9] 9pfs: readdir optimization Christian Schoenebeck
2019-12-18 13:06 ` [PATCH v2 1/9] tests/virtio-9p: add terminating null in v9fs_string_read() Christian Schoenebeck
2020-01-06 11:00   ` Greg Kurz
2019-12-18 13:17 ` [PATCH v2 2/9] 9pfs: validate count sent by client with T_readdir Christian Schoenebeck
2020-01-06 12:30   ` Greg Kurz
2020-01-06 15:10     ` Christian Schoenebeck
2020-01-06 17:49       ` Greg Kurz
2020-01-06 21:43         ` Christian Schoenebeck
2020-01-08 23:53       ` Greg Kurz
2020-01-10 12:03         ` Christian Schoenebeck
2019-12-18 13:23 ` [PATCH v2 3/9] hw/9pfs/9p-synth: added directory for readdir test Christian Schoenebeck
2020-01-09 18:49   ` Greg Kurz
2019-12-18 13:30 ` [PATCH v2 4/9] tests/virtio-9p: added " Christian Schoenebeck
2020-01-06 17:22   ` Greg Kurz
2020-01-07 12:25     ` Christian Schoenebeck [this message]
2020-01-07 15:27       ` Greg Kurz
2020-01-08 23:55   ` Greg Kurz
2020-01-10 12:10     ` Christian Schoenebeck
2019-12-18 13:35 ` [PATCH v2 5/9] tests/virtio-9p: check file names of R_readdir response Christian Schoenebeck
2020-01-06 17:07   ` Greg Kurz
2020-01-07 12:28     ` Christian Schoenebeck
2020-01-07 15:29       ` Greg Kurz
2019-12-18 13:43 ` [PATCH v2 6/9] 9pfs: readdir benchmark Christian Schoenebeck
2019-12-18 13:52 ` [PATCH v2 7/9] hw/9pfs/9p-synth: avoid n-square issue in synth_readdir() Christian Schoenebeck
2019-12-18 14:00 ` [PATCH v2 8/9] 9pfs: T_readdir latency optimization Christian Schoenebeck
2019-12-18 14:10 ` [PATCH v2 9/9] hw/9pfs/9p.c: benchmark time on T_readdir request Christian Schoenebeck

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=10962452.xo9bJ14PLm@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=groug@kaod.org \
    --cc=qemu-devel@nongnu.org \
    /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.