[9fans] 9P2000 and p9p

[9fans] 9P2000 and p9p

[Adriano Verardo]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

Hi, all.

I'm writing a lib to build 9P200 file servers for x86-class embedded 
systems under RTEMS.
Testing the same server under FreeBSD and RTEMS with one Plan9 or 
FreeBSD p9p client I noted some things that I don't understand.

Config: Server = adri (FreeBSD 6.2+fuse+p9p) or leo (RTEMS 4.6.5), 
same    	behaviour
	Client = dria (Plan9 or FreeBSD 6.0+fuse+p9p)

1) Different use of Fids in Plan9 and p9p

Plan9% srv tcp!adri!12000 adri
Plan9% mount /srv/adri /n/adri
Plan9% lc /n/adri (several times)
Plan9% unmount /n/adri

FrBSD% srv 'tcp!adri!12000' adri
FrBSD% 9 mount NS/adri /n/adri
FrBSD% lc /n/adri (several times)
FrBSD% 9 unmount /n/adri

The log of the two sessions above are in the the attached files.
I see that the FreeBDS "lc" command allocates a lot of Fids while
Plan9 reuse them issuing Tclunk messages as soon as possible.
My server use a static Fid table (FidTab=<used>/<total> in the logs).
The number of allocated Fids grows (until the unmount) so a larger table 
(or malloc-ed Fids) is not a solution.

2) Different use of Fids in Plan9 and p9p
The Unix "ls" reuse the Fids as the "lc" does.

3) Tread

 >[ 23] Tread:    tag=4, fid=201, offset=0, count=8192
<[292] Rread:    tag=4, count=281
       E\0\0\0\0\0\0\0\0\0\0\0\0\32\1\0\0\0\0\0\0\37777777666\1\0\0\0
       \0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\7\0file_0a\7\0adriano\7\0adr
 >[ 23] Tread:    tag=4, fid=201, offset=281, count=8192
<[ 11] Rread:    tag=4, count=0

Why the client always sends a second Tread request ?
If the Rread returned 281/8192 bytes and the msize is > 8192 it should 
be clear that there is no other data to read.

Thanks in advance
A. Verardo

[-- Attachment #2: test9P_FreeBSD.txt --]
[-- Type: text/plain, Size: 11453 bytes --]

------------------------------------------------
srv 'tcp!adri!12000' adri
------------------------------------------------

>>>> ENTER SERVER LOOP

>[ 21] Tversion: tag=65535, msize=8192, version='9P2000.u'
<[ 21] Rversion: tag=65535, msize=8192, version='9P2000.u'
------------------------------------------------
9 mount NS/adri /n/adri
------------------------------------------------
>[ 26] Tattach:  tag=0, fid=0, afid=-1, uname='adriano', aname=''
<[ 20] Rattach:  tag=0, qid=[0000000000000111 0 (d)]
>[ 11] Tstat:    tag=0, fid=0 FidTab=1/10
<[ 74] Rstat:    tag=0, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
------------------------------------------------
lc /n/adri
------------------------------------------------
>[ 11] Tstat:    tag=0, fid=0 FidTab=1/10
<[ 74] Rstat:    tag=0, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 17] Twalk:    tag=0, fid=0, newfid=1, nwname=0 
<[  9] Rwalk:    tag=0, nwqid=0 FidTab=2/10 
>[ 12] Topen:    tag=0, fid=1, mode=0x0=RD
<[ 24] Ropen:    tag=0, qid=[0000000000000111 0 (d)], iounit=0
>[ 11] Tclunk:   tag=0, fid=1 FidTab=2/10
<[  7] Rclunk:   tag=0, FidTab=1/10
>[ 17] Twalk:    tag=0, fid=0, newfid=1, nwname=0 
<[  9] Rwalk:    tag=0, nwqid=0 FidTab=2/10 
>[ 12] Topen:    tag=0, fid=1, mode=0x0=RD
<[ 24] Ropen:    tag=0, qid=[0000000000000111 0 (d)], iounit=0
>[ 11] Tstat:    tag=0, fid=0 FidTab=2/10
<[ 74] Rstat:    tag=0, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=0 FidTab=2/10
<[ 74] Rstat:    tag=0, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 23] Tread:    tag=0, fid=1, offset=0, count=8168
<[292] Rread:    tag=0, count=281
      E\0\0\0\0\0\0\0\0\0\0\0\0\32\1\0\0\0\0\0\0\37777777666\1\0\0\0
      \0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\7\0file_0a\7\0adriano\7\0adr
>[ 23] Tread:    tag=0, fid=1, offset=281, count=8168
<[ 11] Rread:    tag=0, count=0
>[ 23] Tread:    tag=0, fid=1, offset=281, count=8168
<[ 11] Rread:    tag=0, count=0
>[ 17] Twalk:    tag=0, fid=0, newfid=2, nwname=0 
<[  9] Rwalk:    tag=0, nwqid=0 FidTab=3/10 
>[ 12] Topen:    tag=0, fid=2, mode=0x0=RD
<[ 24] Ropen:    tag=0, qid=[0000000000000111 0 (d)], iounit=0
>[ 11] Tclunk:   tag=0, fid=2 FidTab=3/10
<[  7] Rclunk:   tag=0, FidTab=2/10
>[ 26] Twalk:    tag=0, fid=0, newfid=2, nwname=1 0:file_0a 
<[ 22] Rwalk:    tag=0, nwqid=1 FidTab=3/10 qid=[000000000000011a 0 ()]

>[ 11] Tstat:    tag=0, fid=2 FidTab=3/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011a 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0a', length=16
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=2 FidTab=3/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011a 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0a', length=16
                 uid='adriano', gid='adriano', muid=''
>[ 26] Twalk:    tag=0, fid=0, newfid=3, nwname=1 0:file_0b 
<[ 22] Rwalk:    tag=0, nwqid=1 FidTab=4/10 qid=[000000000000011b 0 ()]

>[ 11] Tstat:    tag=0, fid=3 FidTab=4/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011b 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0b', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=3 FidTab=4/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011b 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0b', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 26] Twalk:    tag=0, fid=0, newfid=4, nwname=1 0:file_0c 
<[ 22] Rwalk:    tag=0, nwqid=1 FidTab=5/10 qid=[000000000000011c 0 ()]

>[ 11] Tstat:    tag=0, fid=4 FidTab=5/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011c 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0c', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=4 FidTab=5/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011c 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0c', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 23] Twalk:    tag=0, fid=0, newfid=5, nwname=1 0:dir1 
<[ 22] Rwalk:    tag=0, nwqid=1 FidTab=6/10 qid=[0000000000000222 0 (d)]

>[ 11] Tstat:    tag=0, fid=5 FidTab=6/10
<[ 77] Rstat:    tag=0, sz=68/66, type=0, dev=0, qid=[0000000000000222 0 (d)]
                 mode=0x800001FF=QT(DIR)777, at=0, mt=0
                 file='dir1', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=5 FidTab=6/10
<[ 77] Rstat:    tag=0, sz=68/66, type=0, dev=0, qid=[0000000000000222 0 (d)]
                 mode=0x800001FF=QT(DIR)777, at=0, mt=0
                 file='dir1', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 26] Twalk:    tag=0, fid=0, newfid=6, nwname=1 0:file_0a 
<[ 22] Rwalk:    tag=0, nwqid=1 FidTab=7/10 qid=[000000000000011a 0 ()]

>[ 11] Tstat:    tag=0, fid=6 FidTab=7/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011a 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0a', length=16
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=6 FidTab=7/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011a 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0a', length=16
                 uid='adriano', gid='adriano', muid=''
>[ 26] Twalk:    tag=0, fid=0, newfid=7, nwname=1 0:file_0b 
<[ 22] Rwalk:    tag=0, nwqid=1 FidTab=8/10 qid=[000000000000011b 0 ()]

>[ 11] Tstat:    tag=0, fid=7 FidTab=8/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011b 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0b', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=7 FidTab=8/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011b 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0b', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 26] Twalk:    tag=0, fid=0, newfid=8, nwname=1 0:file_0c 
<[ 22] Rwalk:    tag=0, nwqid=1 FidTab=9/10 qid=[000000000000011c 0 ()]

>[ 11] Tstat:    tag=0, fid=8 FidTab=9/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011c 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0c', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=8 FidTab=9/10
<[ 80] Rstat:    tag=0, sz=71/69, type=0, dev=0, qid=[000000000000011c 0 ()]
                 mode=0x1B6=QT(FILE)666, at=0, mt=0
                 file='file_0c', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 23] Twalk:    tag=0, fid=0, newfid=9, nwname=1 0:dir1 
<[ 22] Rwalk:    tag=0, nwqid=1 FidTab=10/10 qid=[0000000000000222 0 (d)]

>[ 11] Tstat:    tag=0, fid=9 FidTab=10/10
<[ 77] Rstat:    tag=0, sz=68/66, type=0, dev=0, qid=[0000000000000222 0 (d)]
                 mode=0x800001FF=QT(DIR)777, at=0, mt=0
                 file='dir1', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tstat:    tag=0, fid=9 FidTab=10/10
<[ 77] Rstat:    tag=0, sz=68/66, type=0, dev=0, qid=[0000000000000222 0 (d)]
                 mode=0x800001FF=QT(DIR)777, at=0, mt=0
                 file='dir1', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tclunk:   tag=0, fid=1 FidTab=10/10
<[  7] Rclunk:   tag=0, FidTab=9/10
------------------------------------------------
lc /n/adri
------------------------------------------------
>[ 11] Tstat:    tag=0, fid=0 FidTab=9/10
<[ 74] Rstat:    tag=0, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 17] Twalk:    tag=0, fid=0, newfid=1, nwname=0 
<[  9] Rwalk:    tag=0, nwqid=0 FidTab=10/10 
>[ 12] Topen:    tag=0, fid=1, mode=0x0=RD
<[ 24] Ropen:    tag=0, qid=[0000000000000111 0 (d)], iounit=0
>[ 11] Tclunk:   tag=0, fid=1 FidTab=10/10
<[  7] Rclunk:   tag=0, FidTab=9/10
>[ 17] Twalk:    tag=0, fid=0, newfid=1, nwname=0 
<[  9] Rwalk:    tag=0, nwqid=0 FidTab=10/10 
>[ 12] Topen:    tag=0, fid=1, mode=0x0=RD
<[ 24] Ropen:    tag=0, qid=[0000000000000111 0 (d)], iounit=0
>[ 11] Tstat:    tag=0, fid=0 FidTab=10/10
<[ 74] Rstat:    tag=0, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 23] Tread:    tag=0, fid=1, offset=0, count=8168
<[292] Rread:    tag=0, count=281
      E\0\0\0\0\0\0\0\0\0\0\0\0\32\1\0\0\0\0\0\0\37777777666\1\0\0\0
      \0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\7\0file_0a\7\0adriano\7\0adr
>[ 23] Tread:    tag=0, fid=1, offset=281, count=8168
<[ 11] Rread:    tag=0, count=0
>[ 23] Tread:    tag=0, fid=1, offset=281, count=8168
<[ 11] Rread:    tag=0, count=0
>[ 17] Twalk:    tag=0, fid=0, newfid=10, nwname=0 
<[ 26] Rerror:   tag=0, ename='no Fids available'
************************************************
Apr 10 16:24:37.686 bad packet - convM2S 0 but 26
************************************************
>[ 11] Tclunk:   tag=1, fid=1 FidTab=10/10
<[  7] Rclunk:   tag=1, FidTab=9/10
------------------------------------------------
9 unmount /n/adri
------------------------------------------------
>[ 11] Tclunk:   tag=1, fid=2 FidTab=9/10
<[  7] Rclunk:   tag=1, FidTab=8/10
>[  9] Tflush:   tag=1, oldtag= 0
<[  7] Rflush:   tag=1, FidTab=8/10
>[ 11] Tclunk:   tag=0, fid=0 FidTab=8/10
<[  7] Rclunk:   tag=0, FidTab=7/10
>[ 11] Tclunk:   tag=0, fid=3 FidTab=7/10
<[  7] Rclunk:   tag=0, FidTab=6/10
>[ 11] Tclunk:   tag=0, fid=4 FidTab=6/10
<[  7] Rclunk:   tag=0, FidTab=5/10
>[ 11] Tclunk:   tag=0, fid=5 FidTab=5/10
<[  7] Rclunk:   tag=0, FidTab=4/10
>[ 11] Tclunk:   tag=0, fid=6 FidTab=4/10
<[  7] Rclunk:   tag=0, FidTab=3/10
>[ 11] Tclunk:   tag=0, fid=7 FidTab=3/10
<[  7] Rclunk:   tag=0, FidTab=2/10
>[ 11] Tclunk:   tag=0, fid=8 FidTab=2/10
<[  7] Rclunk:   tag=0, FidTab=1/10
>[ 11] Tclunk:   tag=0, fid=9 FidTab=1/10
<[  7] Rclunk:   tag=0, FidTab=0/10
>[ 11] Tclunk:   tag=0, fid=10 FidTab=0/10
<[ 36] Rerror:   tag=0, ename='fid unknown or out of range'

-----------------------------------
 END OF TEST
-----------------------------------

[-- Attachment #3: test9P_Plan9.txt --]
[-- Type: text/plain, Size: 4305 bytes --]

-----------------------------------
srv tcp!adri!12000 adri
-----------------------------------

>>>> ENTER SERVER LOOP

-----------------------------------
mount /srv/adri /n/adri
-----------------------------------
>[ 19] Tversion: tag=65535, msize=8216, version='9P2000'
<[ 19] Rversion: tag=65535, msize=8216, version='9P2000'
>[ 22] Tauth:    tag=4, afid=223, uname='adriano', aname=''
<[ 25] Rerror:   tag=4, ename='no auth required'
>[ 26] Tattach:  tag=4, fid=223, afid=-1, uname='adriano', aname=''
<[ 20] Rattach:  tag=4, qid=[0000000000000111 0 (d)]
-----------------------------------
lc /n/adri
-----------------------------------
>[ 17] Twalk:    tag=4, fid=223, newfid=201, nwname=0 
<[  9] Rwalk:    tag=4, nwqid=0 FidTab=2/10 
>[ 11] Tstat:    tag=4, fid=201 FidTab=2/10
<[ 74] Rstat:    tag=4, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tclunk:   tag=4, fid=201 FidTab=2/10
<[  7] Rclunk:   tag=4, FidTab=1/10
>[ 17] Twalk:    tag=4, fid=223, newfid=201, nwname=0 
<[  9] Rwalk:    tag=4, nwqid=0 FidTab=2/10 
>[ 12] Topen:    tag=4, fid=201, mode=0x0=RD
<[ 24] Ropen:    tag=4, qid=[0000000000000111 0 (d)], iounit=0
>[ 23] Tread:    tag=4, fid=201, offset=0, count=8192
<[292] Rread:    tag=4, count=281
      E\0\0\0\0\0\0\0\0\0\0\0\0\32\1\0\0\0\0\0\0\37777777666\1\0\0\0
      \0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\7\0file_0a\7\0adriano\7\0adr
>[ 23] Tread:    tag=4, fid=201, offset=281, count=8192
<[ 11] Rread:    tag=4, count=0
>[ 11] Tclunk:   tag=4, fid=201 FidTab=2/10
<[  7] Rclunk:   tag=4, FidTab=1/10
-----------------------------------
lc /n/adri
-----------------------------------
>[ 17] Twalk:    tag=2, fid=223, newfid=226, nwname=0 
<[  9] Rwalk:    tag=2, nwqid=0 FidTab=2/10 
>[ 11] Tstat:    tag=2, fid=226 FidTab=2/10
<[ 74] Rstat:    tag=2, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tclunk:   tag=2, fid=226 FidTab=2/10
<[  7] Rclunk:   tag=2, FidTab=1/10
>[ 17] Twalk:    tag=2, fid=223, newfid=226, nwname=0 
<[  9] Rwalk:    tag=2, nwqid=0 FidTab=2/10 
>[ 12] Topen:    tag=2, fid=226, mode=0x0=RD
<[ 24] Ropen:    tag=2, qid=[0000000000000111 0 (d)], iounit=0
>[ 23] Tread:    tag=2, fid=226, offset=0, count=8192
<[292] Rread:    tag=2, count=281
      E\0\0\0\0\0\0\0\0\0\0\0\0\32\1\0\0\0\0\0\0\37777777666\1\0\0\0
      \0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\7\0file_0a\7\0adriano\7\0adr
>[ 23] Tread:    tag=2, fid=226, offset=281, count=8192
<[ 11] Rread:    tag=2, count=0
>[ 11] Tclunk:   tag=2, fid=226 FidTab=2/10
<[  7] Rclunk:   tag=2, FidTab=1/10
-----------------------------------
lc /n/adri
-----------------------------------
>[ 17] Twalk:    tag=4, fid=223, newfid=215, nwname=0 
<[  9] Rwalk:    tag=4, nwqid=0 FidTab=2/10 
>[ 11] Tstat:    tag=4, fid=215 FidTab=2/10
<[ 74] Rstat:    tag=4, sz=65/63, type=0, dev=0, qid=[0000000000000111 0 (d)]
                 mode=0x800001B7=QT(DIR)667, at=0, mt=0
                 file='/', length=0
                 uid='adriano', gid='adriano', muid=''
>[ 11] Tclunk:   tag=4, fid=215 FidTab=2/10
<[  7] Rclunk:   tag=4, FidTab=1/10
>[ 17] Twalk:    tag=4, fid=223, newfid=215, nwname=0 
<[  9] Rwalk:    tag=4, nwqid=0 FidTab=2/10 
>[ 12] Topen:    tag=4, fid=215, mode=0x0=RD
<[ 24] Ropen:    tag=4, qid=[0000000000000111 0 (d)], iounit=0
>[ 23] Tread:    tag=4, fid=215, offset=0, count=8192
<[292] Rread:    tag=4, count=281
      E\0\0\0\0\0\0\0\0\0\0\0\0\32\1\0\0\0\0\0\0\37777777666\1\0\0\0
      \0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\7\0file_0a\7\0adriano\7\0adr
>[ 23] Tread:    tag=4, fid=215, offset=281, count=8192
<[ 11] Rread:    tag=4, count=0
>[ 11] Tclunk:   tag=4, fid=215 FidTab=2/10
<[  7] Rclunk:   tag=4, FidTab=1/10
-----------------------------------
unmount /n/adri
-----------------------------------
>[ 11] Tclunk:   tag=2, fid=223 FidTab=1/10
<[  7] Rclunk:   tag=2, FidTab=0/10
-----------------------------------
 END OF TEST
-----------------------------------

Re: [9fans] 9P2000 and p9p

[Charles Forsyth]

>Why the client always sends a second Tread request ?
>If the Rread returned 281/8192 bytes and the msize is > 8192 it should 
>be clear that there is no other data to read.

no, because in general data can be returned as discrete messages (or records) of
different sizes.  for instance with /net/cs and /net/dns each read returns a single
recipe for making a connection or a single translation of a name.
it's true on unix too: think of a magnetic tape drive (probably you can a description
in wikipedia if you never saw one).

Re: [9fans] 9P2000 and p9p

[Adriano Verardo]

Charles Forsyth wrote:

>>Why the client always sends a second Tread request ?
>>If the Rread returned 281/8192 bytes and the msize is > 8192 it should 
>>be clear that there is no other data to read.
> 
> 
> no, because in general data can be returned as discrete messages (or records) of
> different sizes.  for instance with /net/cs and /net/dns each read returns a single
> recipe for making a connection or a single translation of a name.
> it's true on unix too: think of a magnetic tape drive (probably you can a description
> in wikipedia if you never saw one).
> 
> 
Unfortunately I don't need the Wikipedia (first prog in 1975, Univac CII 
10070, punched cards, ...). Nothing to be proud of, I would prefer to be 
25 :-)

Could a EOD field in Rread be useful ? In some cases it would avoid
a lot of messages. I think a very small servers (mController) and low
channels.

Adriano

Re: [9fans] 9P2000 and p9p

[Russ Cox]

> Why the client always sends a second Tread request ?
> If the Rread returned 281/8192 bytes and the msize is > 8192 it should 
> be clear that there is no other data to read.

As Charles pointed out, what you describe is in fact
the behavior of fread(3) (from stdio) but is not the
behavior of the underlying read(2) system call,
even on Unix.  An EOD flag can't work without 
either (a) changing the system call interface or
(b) having some kind of lease so that the EOD can
be invalidated when more data comes in between
the first read and the second read (which you 
propose the operating system should answer without
reference to the 9P server).

The extra fids you see when mounting under Linux
don't grow without bound.  They are being stored
in the Linux vnode cache, and if you build up enough
of them eventually you will start seeing clunks even
before unmounting the file system.  I am sure Eric 
or Ron will chime in with some incantation to disable
this caching in some way.  Plan 9 does not cache 
directory tree information, so you don't see these extra
fids on Plan 9.

Russ

Re: [9fans] 9P2000 and p9p

[C H Forsyth]

>Could a EOD field in Rread be useful ? In some cases it would avoid
>a lot of messages. I think a very small servers (mController) and low
>channels.

yes, although we didn't find it a huge problem on the lego brick,
but then again the timing constraints were fairly lax, even for the lego clock.
we did run a zero-compressing run-length-encoding scheme to compress stat entries
(lots of 28 byte NAMELEN things) and thus directories, but that would have been
less necessary with the current 9p2000/styx encoding; if perhaps still useful.

perhaps more helpfully, note that when reading /dev/time, for instance or especially /dev/bintime,
the application (typically a library function, but not always),
only expects one record, and does just one read, causing just one Tread. cat still works though,
even though it does one extra read (that returns 0).  that's true for some other files too.

Re: [9fans] 9P2000 and p9p

[Adriano Verardo]

C H Forsyth wrote:
>>Could a EOD field in Rread be useful ? In some cases it would avoid
>>a lot of messages. I think a very small servers (mController) and low
>>channels.
> 
> 
> yes, although we didn't find it a huge problem on the lego brick,
> but then again the timing constraints were fairly lax, even for the lego clock.
> we did run a zero-compressing run-length-encoding scheme to compress stat entries
> (lots of 28 byte NAMELEN things) and thus directories, but that would have been
> less necessary with the current 9p2000/styx encoding; if perhaps still useful.

I could have strict timing constraints. I'm trying to understand how 
fast can be a (not too expensive) net of mCtrl coordinated in "Plan9 style".

I read the paper about the Goofy toy (Pisupati, Brown, Indiana Un.), 
based on a TI MSP430. Is there anyone in the 9fans community who tried 
9P2000 on a Microchip's PIC ?

Adriano

Re: [9fans] 9P2000 and p9p

[Adriano Verardo]

Russ Cox wrote:


> As Charles pointed out, what you describe is in fact
> the behavior of fread(3) (from stdio) but is not the
> behavior of the underlying read(2) system call,
> even on Unix.  An EOD flag can't work without 
> either (a) changing the system call interface or
> (b) having some kind of lease so that the EOD can
> be invalidated when more data comes in between
> the first read and the second read (which you 
> propose the operating system should answer without
> reference to the 9P server).
It depends on the time between the two read.
If they were within a few time slices the second
one could return 0 without Tread to to the file server.
The data coming in between the first and second
read is (IMO) a false problem. All would go as the new data
were arrived just after the second (true) read to the file server.
> The extra fids you see when mounting under Linux
> don't grow without bound.  
With an infinite loop of "lc /n/adri" the max is 8630 for
a FreeBSD p9p session. Ok (!?) for RTEMS|VxWorks|eCos|... on x86, not 
for a mCtrl.
Clients under Plan9 would be "the" solution, but sometimes Lunix
is a must.

Adriano

Re: [9fans] 9P2000 and p9p

[Charles Forsyth]

>If they were within a few time slices the second
>one could return 0 without Tread to to the file server.

only if it is psychic.
only the server knows if there is data to be returned at the client's behest

Re: [9fans] 9P2000 and p9p

[Russ Cox]

> It depends on the time between the two read.
> If they were within a few time slices the second
> one could return 0 without Tread to to the file server.
> The data coming in between the first and second
> read is (IMO) a false problem. All would go as the new data
> were arrived just after the second (true) read to the file server.

Your argument assumes no correlation between
the reads and the writes.

Maybe a test program does

	write
	read
	write
	read

Then you will fail the second read incorrectly.

Or maybe correlations between operations on different
machines will yield the same case.

It's fine to assert that playing fast and loose works for
the one case you have in mind.  It's not find to assert
that it works in general.

Russ

Re: [9fans] 9P2000 and p9p

[Adriano Verardo]

Russ Cox wrote:


> Your argument assumes no correlation between
> the reads and the writes.
If they are performed by different machines ...
> 
> Maybe a test program does
> 
> 	write
> 	read
> 	write
> 	read
> 
> Then you will fail the second read incorrectly.
This is a different situation. In the example above read an write are 
done by one program and are  from/to the same file server.
The kernel knows where/when/what it reads/writes.
A task "exec in kernel" (EMT also in Plan9 ? I don't know)
one syscall at a time. To avoid the problem, the read after
a write must be performed ignoring the EOD. The second read in
a read-read seq must be short-circuited when the EOD is active.
Each read sets the EOD (or time window) to guide the kernel for the next 
read.

> Or maybe correlations between operations on different
> machines will yield the same case.
There is no correlation between read and write ops executed on different 
machines to the same file server, wherever it is running on. The second 
zero-data read says that NOW there is no other data to read from that 
server. Thats the same info fread(3) would have from a nbyte(or 0) read 
+ EOD, apart from a slightly difference in the "NOW" absolute time.
Where is the difference ? I think I have a read miss only when an 
asynchronous read returns 0 data AND I'm sure that there is something
to read. If I'm not sure, is as if there were (certainly) nothing to 
read. In other words, the data that is available on the server just a 
pico-sec after the second zero read of the normal cycle is lost or got 
with some delay ? If it is lost, the solution is to delay the second 
read ? 1 psec ? 1 msec ...

... very academic discussion I'm not able to argue in english as I could
(attempt to) do in italian :-(

Of course I'm not thinking to modify the kernel. Instead I think that 
the EOD flag in the Rread packets could be useful for specialised appls 
with a weak interaction with Plan9 (or other 9P speaking higher level 
box), which should ignore it at all.
To have only one protocol for low<->low and low<->high levels 
communications.


Adriano

Re: [9fans] 9P2000 and p9p

[Kris Maglione]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

On Tue, Apr 10, 2007 at 07:12:27PM +0200, Adriano Verardo wrote:
>The log of the two sessions above are in the the attached files.
>I see that the FreeBDS "lc" command allocates a lot of Fids while
>Plan9 reuse them issuing Tclunk messages as soon as possible.

There's more to it than that. Unfortunately, p9p's ls calls p9p's 
readdir. Since readdir on Plan 9 has to return a complete Stat for each 
file in a directory, p9p's readdir stats every file in the directory, 
whether the caller needs the data or not (ls doesn't, without the ls 
flag). That means that the p9p lc needs to walk to each directory entry, 
whereas Plan 9's doesn't.

-- 
Kris Maglione

Things equal to nothing else are equal to each other.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] 9P2000 and p9p

[erik quanstrom]

> This is a different situation. In the example above read an write are 
> done by one program and are  from/to the same file server.
> The kernel knows where/when/what it reads/writes.
> A task "exec in kernel" (EMT also in Plan9 ? I don't know)
> one syscall at a time. To avoid the problem, the read after
> a write must be performed ignoring the EOD. The second read in
> a read-read seq must be short-circuited when the EOD is active.
> Each read sets the EOD (or time window) to guide the kernel for the next 
> read.
> 

i don't understand the problem you're trying to solve.  this seems like
a special case.  maybe as such, you want a protocol other than 9p.

the great thing about plan 9 is it's a way of working.  it's not a protocol
or implementation.

- erik

Re: [9fans] 9P2000 and p9p

[Russ Cox]

> There is no correlation between read and write ops executed on different 
> machines to the same file server, wherever it is running on. 

This is not true.

Suppose two programs running on two different machines
are communicating directly but also using a shared file server.

Then program A could write something to a file, tell program B
there was new data in the file, and program B could read it.
Repeat.  You get the same write, read, write, read sequence
I gave before, but without any central kernel that knows enough
to second-guess the EOD tag on the first read response -- the
reads happen using one machine, the writes using another.

You are proposing a clumsy fix to a problem that you haven't
actually demonstrated to exist.  The extra read is just not 
costly enough in practice to justify the extra complexity.

You are already doing Twalk Topen Tread Tclunk.  A second 
Tread won't hurt very much.  If you really care about minimizing
the number of requests, you'd do better to have a single "events"
file that got opened once and then polled (with blocking reads)
to get information out of the device.

Russ

Re: [9fans] 9P2000 and p9p

[Bruce Ellis]

can i say that EOD is useless on synthesized files.  may be good
on readonly stuff.  i hate the extra read of 0 but get over it.

as presto once said "are you just whining or preposing a solution?".

brucee

On 4/11/07, Russ Cox <rsc@swtch.com> wrote:
> > There is no correlation between read and write ops executed on different
> > machines to the same file server, wherever it is running on.
>
> This is not true.
>
> Suppose two programs running on two different machines
> are communicating directly but also using a shared file server.
>
> Then program A could write something to a file, tell program B
> there was new data in the file, and program B could read it.
> Repeat.  You get the same write, read, write, read sequence
> I gave before, but without any central kernel that knows enough
> to second-guess the EOD tag on the first read response -- the
> reads happen using one machine, the writes using another.
>
> You are proposing a clumsy fix to a problem that you haven't
> actually demonstrated to exist.  The extra read is just not
> costly enough in practice to justify the extra complexity.
>
> You are already doing Twalk Topen Tread Tclunk.  A second
> Tread won't hurt very much.  If you really care about minimizing
> the number of requests, you'd do better to have a single "events"
> file that got opened once and then polled (with blocking reads)
> to get information out of the device.
>
> Russ
>
>

Re: [9fans] 9P2000 and p9p

[Charles Forsyth]

> Tread won't hurt very much.  If you really care about minimizing
> the number of requests, you'd do better to have a single "events"
> file that got opened once and then polled (with blocking reads)
> to get information out of the device.

yes. we do that often; it works well.  think of it as `publish/subscribe'
for the 21st century: instead of lots of peculiar new APIs and Pattern Names,
you open a file, and if needed write a subscription description; and read from it.
the server knows.

Re: [9fans] 9P2000 and p9p

[ron minnich]

On 4/11/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > Tread won't hurt very much.  If you really care about minimizing
> > the number of requests, you'd do better to have a single "events"
> > file that got opened once and then polled (with blocking reads)
> > to get information out of the device.
>
> yes. we do that often; it works well.  think of it as `publish/subscribe'
> for the 21st century: instead of lots of peculiar new APIs and Pattern Names,
> you open a file, and if needed write a subscription description; and read from it.
> the server knows.
>

plus, if you desperately need EOD, and it's your server, and only your
client, then put an EOD indicator in the data. I.e., there is a
claimed need to avoid the second tread for some reason. This need
stands outside what 9p does, and this 'second tread avoidance' is not
needed by any other 9p server or client, save for your client and your
server. So make every first byte of the packet sent by the server be
metadata providing additional information about the data in the
packet. You can use that first byte to be your EOD.

yeah, yeah, it's gross, but I've seen this sort of thing done where
"it really matters". The point is that there is nothing about 9p
clients and servers that rules this metadata out, and the fact that
the server is a program, written by you, makes this metadata very easy
to add in.

thanks

ron