From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D741C433B4 for ; Wed, 7 Apr 2021 08:54:13 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7DD596124B for ; Wed, 7 Apr 2021 08:54:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DD596124B Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=crudebyte.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:37530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lU3wx-0004uw-Kp for qemu-devel@archiver.kernel.org; Wed, 07 Apr 2021 04:54:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU3vy-000467-JJ for qemu-devel@nongnu.org; Wed, 07 Apr 2021 04:53:10 -0400 Received: from kylie.crudebyte.com ([5.189.157.229]:39825) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU3vw-0001Mu-E7 for qemu-devel@nongnu.org; Wed, 07 Apr 2021 04:53:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crudebyte.com; s=kylie; h=Content-Type:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Content-ID:Content-Description; bh=p3cyy6JD8fANw3oaunjybaLD1iLjfQOVAUIN8gwlUyw=; b=MSLvP41mTw+daOtBEf6U+KhFHS eHi7cF3Tw8qfnOu9PISGDmqDWA4Sn1Y+qZ8yFTjxkwKcYY50LsgrJkjDvnlivkg2PSgICbmiEf2Z4 fsrdAGblHEL5vmqltFmjOd/LiP6A5hkjDvojNTkrpsg4gELf797b5DzS0XqCEL0YDMJN2HkKUyC6f UcUM+17DhBVCaMzPSEul8EYBMlxKJ9D3ZsNFYvE7eFzxGGnLoQwJb34YAFAH5obDPDVNZjPHOiI85 nJ4kX3xCROFTunON3HMgipaHBwTv9db5MP7EhCNW2BptXzPsoannZmvyuxHlZcuxtZowNyDRJRzHB jYaZvWpJskOCOo66WiR+xvwrbWATp1k49zkKwa1k4YM+YMdXk3ROMDTr3mJyNw0D+gPE9Iz2DddDr eaacAxcA5lmGMBSWenONYePs/LfWgRJqeX3sxrPRNX+mZHPkNWXrzkmFVWpYvEM3C8qA7ha97ntRM +CduW1qN62sfdsch6DSNANpbXinN86VRwxHLGn6IEc8v46HE+AmWTzDCxiQ86mimCQaoc0RJskHQr GKyByhZ+1v1RTRdS3MNIWH3GxGmVjzqDaHGVp1fWbU4Kt757L4356UfqCao66AMbg6of17iyxhjOw 6++eOuLwV0LILByiESR3KkI6/ciT9jM/NV+PgKW98=; From: Christian Schoenebeck To: qemu-devel@nongnu.org Cc: Greg Kurz , Paolo Bonzini , Peter Maydell Subject: Re: [PATCH 0/4] add in-tree 9pfs developers documentation Date: Wed, 07 Apr 2021 10:52:59 +0200 Message-ID: <2001177.cHeAXU27Kk@silver> In-Reply-To: <20210407093230.5b172a8a@bahia.lan> References: <3541529.Jmkro1RegT@silver> <20210407093230.5b172a8a@bahia.lan> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Received-SPF: pass client-ip=5.189.157.229; envelope-from=qemu_oss@crudebyte.com; helo=kylie.crudebyte.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mittwoch, 7. April 2021 09:32:30 CEST Greg Kurz wrote: > On Tue, 06 Apr 2021 14:27:41 +0200 >=20 > Christian Schoenebeck wrote: > > On Dienstag, 23. M=E4rz 2021 20:40:20 CEST Christian Schoenebeck wrote: > > > The original source for the QEMU 9p developers documentation is: > > > https://wiki.qemu.org/Documentation/9p > > >=20 > > > This patch set adds it as in-tree .rst file along with its pictures to > > > the > > > QEMU source tree. The 9p.rst file has been auto generated by 'pandoc'. > > >=20 > > > Preview of generated 9p.rst file with pictures: > > >=20 > > >=20 > > > https://github.com/cschoenebeck/qemu/blob/bbc74655d54f2fa9c3eabf485e8= 7f9 > > > 952 > > > 53b8cfd/docs/devel/9p.rst > > >=20 > > > Picture binary files (omitted as binary blobs from patch 2): > > >=20 > > >=20 > > > https://github.com/cschoenebeck/qemu/tree/bbc74655d54f2fa9c3eabf485e8= 7f9 > > > 952 > > > 53b8cfd/docs/devel/img > > >=20 > > > Or simply access my '9p.experimental' branch on github. > > >=20 > > > I have no idea if that fits into the current sphinx/meson concept in > > > this > > > form and way. I hope either Peter or Paolo might tell. > > >=20 > > > The individual patches could also be squashed, I kept them split for = now > > > to > > > show what pandoc actually did and what I manually adjusted afterwards. > > >=20 > > > Christian Schoenebeck (4): > > > docs/devel: add 9p.rst > > > docs/devel: add directory for pictures > > > docs/devel/9p: fix references to pictures > > > MAINTAINERS: add responsibility for docs/devel/9p.rst > >=20 > > Ping > >=20 > > Anyone? On doubt I just leave the 9p developer docs solely on the wiki > > site. > Hi Christian, >=20 > Sorry for the delay... well, it is probably handy to have some > in-tree documentation. This being said I can't really tell if > it makes sense to have an exact copy of the wiki... or if this > should simply replace the wiki. The idea was to keep the wiki page as primary copy and only sync the in-tre= e=20 =2Erst file by auto conversion tool (e.g. pandoc) once in a while. Because = it is=20 easier, quicker and more convenient to quickly change docs by wiki IMO. > Also, do we want to host the png files ? It seems that other > in-tree documentation rather relies on ASCII-art, which > provides a more terminal-friendly experience. Right, that's a matter of taste / opinion. I assume a small minority of peo= ple=20 want to be able to view illustrations from a text terminal nowadays, and th= at=20 the vast majority rather prefers a graphical representation. The lack of co= lor=20 alone would already be too counter intuitive in my opinion, and automatic=20 ascii art conversion tools never worked for me well enough. Given the fact that we can only spend small times slices on 9p, I would lik= e=20 to avoid maintaining 2 completely separate documentation versions manually. So personally I would suggest, if either auto conversion and/or images is n= ot=20 appropriate for an in-tree version, to just keep the wiki page for now.=20 >=20 > Cheers, >=20 > -- > Greg >=20 > > > MAINTAINERS | 1 + > > > docs/devel/9p.rst | 544 +++++++++++++++++++++++++= ++ > > > docs/devel/img/9pfs_control_flow.png | Bin 0 -> 156560 bytes > > > docs/devel/img/9pfs_topology.png | Bin 0 -> 51529 bytes > > > docs/devel/img/Coroutines_stacks.png | Bin 0 -> 87204 bytes > > > 5 files changed, 545 insertions(+) > > > create mode 100644 docs/devel/9p.rst > > > create mode 100644 docs/devel/img/9pfs_control_flow.png > > > create mode 100644 docs/devel/img/9pfs_topology.png > > > create mode 100644 docs/devel/img/Coroutines_stacks.png > >=20 > > Best regards, > > Christian Schoenebeck