All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: 9pfs developers docs
Date: Mon, 1 Feb 2021 13:26:49 +0100	[thread overview]
Message-ID: <20210201132649.6db25cec@bahia.lan> (raw)
In-Reply-To: <3962897.vStEPALNoS@silver>

On Mon, 01 Feb 2021 12:30:52 +0100
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Montag, 1. Februar 2021 10:24:26 CET Greg Kurz wrote:
> > On Sun, 31 Jan 2021 19:23:52 +0100
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > Hi,
> > 
> > Hi Christian,
> > 
> > > I started setting up some developer documentation for 9pfs:
> > > 	https://wiki.qemu.org/Documentation/9p
> > > 
> > > Still quite a bunch that should be added (e.g. there should be a section
> > > about threads and coroutines), but at least it's a start ...
> > 
> > I agree that a bunch of other things should be documented, but that's
> > definitely a great start. Thanks for doing this !
> > 
> > Just one remark on the topology diagram:
> > 
> > https://wiki.qemu.org/File:9pfs_topology.png
> > 
> > It gives the impression that the 9p transport and server can
> > handle multiple guests, which they certainly don't : each
> > 9p server lives in exactly one device which is exposed to
> > exactly one guest.
> 
> Right, I haven't considered that the diagram might be interpreted that way. My 
> primary intention was to show the 3 main components of 9pfs from design 
> perspective and secondary showing that multiple guests can share storage.
> 
> So what would be better: a) duplicating the server side in the diagram (then 
> the image might become a bit large in height), b) dropping the multiple 
> guests, c) making the issue with server instances clear in the text?

I'd rather go for b)

> 
> If there are other things that you might think should be outlined by 
> additional diagram(s) let me know, then I can add that in one rush.
> 
> --
> 
> BTW I'm no longer able to run the 'local' 9p tests, --slow doesn't work for 
> me. If you don't have an idea what I might be missing, then I have to look why 
> the CLI parameter is not interpreted.
> 

Is it that '-m slow' doesn't work when running 'qos-test' or
that 'make check-qtest SPEEP=slow' doesn't run the slow tests ?

The latter was discussed on IRC last year but I don't know if
anyone has tried to investigate this yet.

Nov 24 11:36:53 <groug>	th_huth, Hi. FYI it seems that the meson conversion kinda broke 'make check SPEED=slow'. Test programs aren't passed '-m slow'
Nov 24 11:51:42 <f4bug>	th_huth: do you know who uses/tests SPEED=slow?
Nov 24 11:52:03 <f4bug>	th_huth: I thought this was a block-related feature
Nov 24 11:52:44 <groug>	f4bug, it is supposedly used by gitlab CI
Nov 24 11:52:59 <groug>	.gitlab-ci.yml:    MAKE_CHECK_ARGS: check-qtest SPEED=slow
Nov 24 12:50:53 <th_huth>	groug, I'm also running make check SPEED=slow manually sometimes ... I guess that got lost in the conversion to ninja ... bonzini, did you ever try?
Nov 24 12:51:03 <bonzini>	no it shouldn't
Nov 24 12:51:21 <th_huth>	let me check...
Nov 24 12:51:40 <bonzini>	ah, the tests are chosen correctly but -m slow is lost
Nov 24 12:52:02 <groug>	yes that's what I see
Nov 24 12:54:04 <groug>	bonzini, missing bits in scripts/mtest2make.py ?
Nov 24 12:54:28 <bonzini>	groug: sort of, but assuming that all executables support -m slow wouldn't work

Cc'ing Thomas and Paolo for additional details.

> Best regards,
> Christian Schoenebeck
> 
> 



  reply	other threads:[~2021-02-01 12:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-31 18:23 9pfs developers docs Christian Schoenebeck
2021-02-01  9:24 ` Greg Kurz
2021-02-01 11:30   ` Christian Schoenebeck
2021-02-01 12:26     ` Greg Kurz [this message]
2021-02-01 13:15       ` Paolo Bonzini
2021-02-01 13:37       ` qemu_oss--- via
2021-02-25 16:31         ` Christian Schoenebeck
2021-02-25 16:47           ` Greg Kurz
2021-02-01 11:42 ` Peter Maydell
2021-02-01 13:44   ` 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=20210201132649.6db25cec@bahia.lan \
    --to=groug@kaod.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    --cc=thuth@redhat.com \
    /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.