From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pb-smtp2.pobox.com ([64.147.108.71]) by ewsd; Sun May 17 20:18:28 EDT 2020 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EB58F5ABF5; Sun, 17 May 2020 20:18:14 -0400 (EDT) (envelope-from unobe@cpan.org) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date :in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:to:from:message-id; s=sasl; bh=e+91pK1Z7l/W6e+CUE+fYvkEv8w=; b=yPx3ySt4TThUd2ZsDPwWvCfD5ZvQ pRa66kB+DN96+FovlKB0Jr1k2TuBPSU/SxyEy/5dEMa/TiU3WGTjAZ4DVWG7UmQZ rI9Rmsvqkqh5y/Q8oUB/jbPmz+y1KI1AFRhjTNbaqPmwje9R4gnYsxG0GktYjW0H +mPcg5QY5CrXuR8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E34375ABF4; Sun, 17 May 2020 20:18:14 -0400 (EDT) (envelope-from unobe@cpan.org) Received: from [IPv6:2607:fb90:4e9c:a4e8:7fd9:c67e:b516:5c1c] (unknown [172.58.27.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 9AB2A5ABF2; Sun, 17 May 2020 20:18:13 -0400 (EDT) (envelope-from unobe@cpan.org) Date: Mon, 18 May 2020 00:18:09 +0000 In-Reply-To: References: <2DE413B1-B05D-45EF-A08A-6F9F119FB745@cpan.org> <436A949A-4A55-4F46-936B-F369038CCB47@cpan.org> <133678F3-1EA1-446D-9313-F10F23C84936@cpan.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: 9P2000.s vs 9P2020 vs. ? (Was Re: [9front] Slow cp, support for 9P2000.s) To: 9front@9front.org,Roman Shaposhnik From: Romano Message-ID: <35A57A8E-E288-4395-A08F-2EE3F6967F79@cpan.org> X-Pobox-Relay-ID: 10269986-989D-11EA-852F-D1361DBA3BAF-09620299!pb-smtp2.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: extensible shared content-driven hardware base framework https://pdfs=2Esemanticscholar=2Eorg/9b47/22e251df61b4abbe0da61720e57ac7b62= f61=2Epdf On May 18, 2020 12:07:13 AM UTC, Roman Shaposhnik = wrote: >On Wed, May 13, 2020 at 1:27 AM Romano wrote: >> >> Since there's no existing discussion I can see, and IRC isn't meant >for searching for answers to questions, is there anyone willing to >summarize the state of solving problems like streaming for 9P? >> >> If Aiju remembers correctly, there were two things where 9P2000=2Es was >found wanting: >> 1) it breaks the syscall interface; and >> 2) it forces 9P to run over TCP=2E >> >> FWIW, I finally finished reading through all of John's thesis, rather >than just skimming, and I think John did a nice review of the previous >work done in this area and presenting why he chose the solution he did=2E >His solution used TCP, but from his write-up, I don't see a technical >reason why another transport protocol[1] could not be used=2E That would >leave only breaking the syscall interface=2E > >Any chance to see a link to John's thesis? > >> Does breaking the syscall interface mean that it's merely adding a >syscall? Or does it mean something else? >> >> Right now hget(1) is an rc script that uses webfs(4)=2E So if I'm at a >terminal far away and am using webfs provided by the server I'm >connected to, hget would be slow for a large file because the file >would be transferred over 9P=2E It's no better than Plan 9's >implementation, but no worse either=2E >> >> [1] https://en=2Ewikipedia=2Eorg/wiki/Category:Transport_layer_protocol= s