* [9fans] german keymap
@ 2004-04-11 19:14 Scusi
2004-04-11 19:28 ` boyd, rounin
2004-04-11 22:10 ` Geoff Collyer
0 siblings, 2 replies; 67+ messages in thread
From: Scusi @ 2004-04-11 19:14 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
Hi 9fans,
thank you for your help regarding the keymap issue. I got it solved,
attached you find the german keymap is suitable for my IBM T20.
I haven't tested it on any other system, but the scancodes look the
same on my T30 Laptop, so it is hopefully also working at least on other
IBM Thinkpads.
In any case it should be a good starting point to other german keyboards.
Because i found no way with "unicode" and "ascii" to get the decimal value
for stuff i found in /lib/unicode. i wrote a littel tool that simply takes
a hex value and gives back the value as a decimal integer. the tool is
called "hex2dec" and is also attached. Maybe it is useful for other ppl
that need to write their own keymap. Feel free to send me comments about
my code, since i'm just learning c constructive feedback is welcome.
One speciality in the keymap is that i put small greek kappa letter on
AltGr + k, because i found it handy for binding the kbmap device ;-)
Cheers /~scusi
[-- Attachment #2: de --]
[-- Type: application/octet-stream, Size: 23597 bytes --]
0 0 0
0 1 27
0 2 49
0 3 50
0 4 51
0 5 52
0 6 53
0 7 54
0 8 55
0 9 56
0 10 57
0 11 48
0 12 223
0 13 39
0 14 8
0 15 9
0 16 113
0 17 119
0 18 101
0 19 114
0 20 116
0 21 122
0 22 117
0 23 105
0 24 111
0 25 112
0 26 252
0 27 43
0 28 10
0 29 63586
0 30 97
0 31 115
0 32 100
0 33 102
0 34 103
0 35 104
0 36 106
0 37 107
0 38 108
0 39 246
0 40 228
0 41 94
0 42 63584
0 43 35
0 44 121
0 45 120
0 46 99
0 47 118
0 48 98
0 49 110
0 50 109
0 51 44
0 52 46
0 53 45
0 54 63584
0 55 42
0 56 63587
0 57 32
0 58 63586
0 59 61441
0 60 61442
0 61 61443
0 62 61444
0 63 61445
0 64 61446
0 65 61447
0 66 61448
0 67 61449
0 68 61450
0 69 63589
0 70 61461
0 71 55
0 72 56
0 73 57
0 74 45
0 75 52
0 76 53
0 77 54
0 78 43
0 79 49
0 80 50
0 81 51
0 82 48
0 83 46
0 84 0
0 85 0
0 86 60
0 87 61451
0 88 61452
0 89 0
0 90 0
0 91 0
0 92 0
0 93 0
0 94 0
0 95 0
0 96 0
0 97 0
0 98 0
0 99 0
0 100 0
0 101 0
0 102 0
0 103 0
0 104 0
0 105 0
0 106 0
0 107 0
0 108 0
0 109 0
0 110 0
0 111 0
0 112 0
0 113 0
0 114 0
0 115 0
0 116 0
0 117 0
0 118 0
0 119 0
0 120 0
0 121 63488
0 122 0
0 123 61454
0 124 0
0 125 0
0 126 0
0 127 0
1 0 0
1 1 176
1 2 33
1 3 34
1 4 35
1 5 36
1 6 37
1 7 38
1 8 47
1 9 40
1 10 41
1 11 61
1 12 63
1 13 180
1 14 8
1 15 9
1 16 81
1 17 87
1 18 69
1 19 82
1 20 84
1 21 90
1 22 85
1 23 73
1 24 79
1 25 80
1 26 220
1 27 42
1 28 10
1 29 63586
1 30 65
1 31 83
1 32 68
1 33 70
1 34 71
1 35 72
1 36 74
1 37 75
1 38 76
1 39 246
1 40 196
1 41 176
1 42 63584
1 43 39
1 44 89
1 45 88
1 46 67
1 47 86
1 48 66
1 49 78
1 50 77
1 51 59
1 52 58
1 53 95
1 54 63584
1 55 42
1 56 63587
1 57 32
1 58 63586
1 59 61441
1 60 61442
1 61 61443
1 62 61444
1 63 61445
1 64 61446
1 65 61447
1 66 61448
1 67 61449
1 68 61450
1 69 63589
1 70 61461
1 71 55
1 72 56
1 73 57
1 74 45
1 75 52
1 76 53
1 77 54
1 78 43
1 79 49
1 80 50
1 81 51
1 82 48
1 83 46
1 84 0
1 85 0
1 86 62
1 87 61451
1 88 61452
1 89 0
1 90 0
1 91 0
1 92 0
1 93 0
1 94 0
1 95 0
1 96 0
1 97 0
1 98 0
1 99 0
1 100 0
1 101 0
1 102 0
1 103 0
1 104 0
1 105 0
1 106 0
1 107 0
1 108 0
1 109 0
1 110 0
1 111 0
1 112 0
1 113 0
1 114 0
1 115 0
1 116 0
1 117 0
1 118 0
1 119 0
1 120 0
1 121 61454
1 122 0
1 123 61454
1 124 0
1 125 0
1 126 0
1 127 0
2 0 0
2 1 0
2 2 0
2 3 0
2 4 0
2 5 0
2 6 0
2 7 0
2 8 0
2 9 0
2 10 0
2 11 0
2 12 0
2 13 0
2 14 0
2 15 0
2 16 64
2 17 0
2 18 0
2 19 0
2 20 0
2 21 0
2 22 0
2 23 0
2 24 0
2 25 0
2 26 0
2 27 126
2 28 10
2 29 63586
2 30 0
2 31 0
2 32 0
2 33 0
2 34 0
2 35 0
2 36 0
2 37 0
2 38 0
2 39 0
2 40 0
2 41 0
2 42 63584
2 43 0
2 44 0
2 45 0
2 46 0
2 47 0
2 48 0
2 49 0
2 50 181
2 51 0
2 52 0
2 53 43
2 54 0
2 55 61456
2 56 63591
2 57 0
2 58 0
2 59 0
2 60 0
2 61 0
2 62 0
2 63 0
2 64 0
2 65 0
2 66 0
2 67 0
2 68 0
2 69 0
2 70 63585
2 71 61453
2 72 61454
2 73 61455
2 74 0
2 75 61457
2 76 0
2 77 61458
2 78 0
2 79 61464
2 80 63488
2 81 61459
2 82 61460
2 83 127
2 84 0
2 85 0
2 86 124
2 87 0
2 88 0
2 89 0
2 90 0
2 91 0
2 92 0
2 93 0
2 94 0
2 95 0
2 96 0
2 97 0
2 98 0
2 99 0
2 100 0
2 101 0
2 102 0
2 103 0
2 104 0
2 105 0
2 106 0
2 107 0
2 108 0
2 109 0
2 110 0
2 111 0
2 112 0
2 113 0
2 114 0
2 115 0
2 116 0
2 117 0
2 118 0
2 119 0
2 120 0
2 121 61454
2 122 0
2 123 0
2 124 0
2 125 0
2 126 0
2 127 0
3 0 0
3 1 0
3 2 0
3 3 0
3 4 0
3 5 0
3 6 0
3 7 0
3 8 123
3 9 91
3 10 93
3 11 125
3 12 92
3 13 0
3 14 0
3 15 0
3 16 64
3 17 0
3 18 8352
3 19 0
3 20 0
3 21 0
3 22 0
3 23 0
3 24 0
3 25 0
3 26 0
3 27 126
3 28 10
3 29 63586
3 30 0
3 31 0
3 32 0
3 33 0
3 34 0
3 35 0
3 36 0
3 37 954
3 38 0
3 39 0
3 40 0
3 41 0
3 42 63584
3 43 0
3 44 0
3 45 0
3 46 0
3 47 0
3 48 0
3 49 0
3 50 181
3 51 0
3 52 0
3 53 43
3 54 0
3 55 61456
3 56 63591
3 57 0
3 58 0
3 59 0
3 60 0
3 61 0
3 62 0
3 63 0
3 64 0
3 65 0
3 66 0
3 67 0
3 68 0
3 69 0
3 70 63585
3 71 61453
3 72 61454
3 73 61455
3 74 0
3 75 61457
3 76 0
3 77 61458
3 78 0
3 79 61464
3 80 63488
3 81 61459
3 82 61460
3 83 127
3 84 0
3 85 0
3 86 124
3 87 0
3 88 0
3 89 0
3 90 0
3 91 0
3 92 0
3 93 0
3 94 0
3 95 0
3 96 0
3 97 0
3 98 0
3 99 0
3 100 0
3 101 0
3 102 0
3 103 0
3 104 0
3 105 0
3 106 0
3 107 0
3 108 0
3 109 0
3 110 0
3 111 0
3 112 0
3 113 0
3 114 0
3 115 0
3 116 0
3 117 0
3 118 0
3 119 0
3 120 0
3 121 61454
3 122 0
3 123 0
3 124 0
3 125 0
3 126 0
3 127 0
4 0 0
4 1 27
4 2 17
4 3 18
4 4 19
4 5 20
4 6 21
4 7 22
4 8 23
4 9 24
4 10 25
4 11 16
4 12 13
4 13 29
4 14 8
4 15 9
4 16 17
4 17 23
4 18 5
4 19 18
4 20 20
4 21 25
4 22 21
4 23 9
4 24 15
4 25 16
4 26 27
4 27 29
4 28 10
4 29 63586
4 30 1
4 31 19
4 32 4
4 33 6
4 34 7
4 35 8
4 36 10
4 37 11
4 38 12
4 39 27
4 40 7
4 41 0
4 42 63584
4 43 28
4 44 26
4 45 24
4 46 3
4 47 22
4 48 2
4 49 14
4 50 13
4 51 12
4 52 14
4 53 15
4 54 63584
4 55 10
4 56 63587
4 57 0
4 58 63586
4 59 5
4 60 6
4 61 7
4 62 4
4 63 5
4 64 6
4 65 7
4 66 12
4 67 13
4 68 14
4 69 5
4 70 6
4 71 23
4 72 24
4 73 25
4 74 13
4 75 20
4 76 21
4 77 22
4 78 11
4 79 17
4 80 18
4 81 19
4 82 16
4 83 14
4 84 0
4 85 0
4 86 124
4 87 15
4 88 12
4 89 0
4 90 0
4 91 0
4 92 0
4 93 0
4 94 0
4 95 0
4 96 0
4 97 0
4 98 0
4 99 0
4 100 0
4 101 0
4 102 0
4 103 0
4 104 0
4 105 0
4 106 0
4 107 0
4 108 0
4 109 0
4 110 0
4 111 0
4 112 0
4 113 0
4 114 0
4 115 0
4 116 0
4 117 0
4 118 0
4 119 0
4 120 0
4 121 7
4 122 0
4 123 8
4 124 0
4 125 0
4 126 0
4 127 0
[-- Attachment #3: hex2dec.c --]
[-- Type: application/octet-stream, Size: 507 bytes --]
/* hex2dec.c - translates hex values to decimal integer values.
* (plan9 version)
* written by: <scusi@xs4all.nl>
* date: Sun Apr 11 2004
*/
#include <u.h>
#include <libc.h>
#include <stdio.h>
int main (int argc, char* argv[])
{
printf("/-- hex2dec (plan9) <scusi@xs4all.nl>\n");
if (argc !=2)
{
printf("usage: %s hex\n", argv[0]);
return(1);
}
printf("value as decimal integer: %i\n", (unsigned int)(strtoul(argv[1], (char **) NULL, 16)));
return(0);
}
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 19:14 [9fans] german keymap Scusi
@ 2004-04-11 19:28 ` boyd, rounin
2004-04-11 20:00 ` Scusi
2004-04-11 22:10 ` Geoff Collyer
1 sibling, 1 reply; 67+ messages in thread
From: boyd, rounin @ 2004-04-11 19:28 UTC (permalink / raw)
To: 9fans
> thank you for your help regarding the keymap issue. I got it solved,
> attached you find the german keymap is suitable for my IBM T20.
cool. does a german keyboard look like this?
http://www.insultant.net/uk/BP2004/DSC00551.JPG
you might like this:
vr.c which is a dumb filter to debug rune problems, outputing glyph,
Unicode value, UTF sequence and an optional comment.
http://www.insultant.net/code/plan9/vr.c
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 19:28 ` boyd, rounin
@ 2004-04-11 20:00 ` Scusi
2004-04-11 20:03 ` boyd, rounin
0 siblings, 1 reply; 67+ messages in thread
From: Scusi @ 2004-04-11 20:00 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
On Sun, 11 Apr 2004 21:28:55 +0200
"boyd, rounin" <boyd@insultant.net> wrote:
> > thank you for your help regarding the keymap issue. I got it solved,
> > attached you find the german keymap is suitable for my IBM T20.
>
> cool. does a german keyboard look like this?
>
> http://www.insultant.net/uk/BP2004/DSC00551.JPG
yeah, basically.
>
> you might like this:
>
> vr.c which is a dumb filter to debug rune problems, outputing glyph,
> Unicode value, UTF sequence and an optional comment.
>
> http://www.insultant.net/code/plan9/vr.c
>
>
well, sort of what i looked for.
Actually i just found out, that there is one character missing.
i attached a patch for it.
But now it is good, i double checked each key.
/~scusi
[-- Attachment #2.1: Type: text/plain, Size: 363 bytes --]
from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless. To avoid possible automatic
execution, we changed the content headers.
The original header was:
Content-Type: application/octet-stream;
name="kbmap.de.patch"
Content-Disposition: attachment;
filename="kbmap.de.patch"
Content-Transfer-Encoding: base64
[-- Attachment #2.2: kbmap.de.patch.suspect --]
[-- Type: application/octet-stream, Size: 92 bytes --]
389c389
< 3 4 0
---
> 3 4 167
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 20:00 ` Scusi
@ 2004-04-11 20:03 ` boyd, rounin
0 siblings, 0 replies; 67+ messages in thread
From: boyd, rounin @ 2004-04-11 20:03 UTC (permalink / raw)
To: 9fans
> > cool. does a german keyboard look like this?
> >
> > http://www.insultant.net/uk/BP2004/DSC00551.JPG
>
> yeah, basically.
that's why i took the shot, so i'd have an idea of what one might look like
now.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 19:14 [9fans] german keymap Scusi
2004-04-11 19:28 ` boyd, rounin
@ 2004-04-11 22:10 ` Geoff Collyer
2004-04-11 22:39 ` Russ Cox
2004-04-21 17:43 ` rog
1 sibling, 2 replies; 67+ messages in thread
From: Geoff Collyer @ 2004-04-11 22:10 UTC (permalink / raw)
To: 9fans
One can convert between decimal and other bases (radices) using bc, by
setting the input or output base:
; bc
ob=16
1024
400
<eot>; bc
ib=16
400
1024
<eot>;
For more general radix conversion, I use db:
: cpu; db
cannot open `8.out': '8.out' directory entry not found
386 binary
0x400=D
1024
0t1024=X
0x400
0400=D
256
0400=X
0x100
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 22:10 ` Geoff Collyer
@ 2004-04-11 22:39 ` Russ Cox
2004-04-11 22:55 ` Geoff Collyer
2004-04-12 2:33 ` boyd, rounin
2004-04-21 17:43 ` rog
1 sibling, 2 replies; 67+ messages in thread
From: Russ Cox @ 2004-04-11 22:39 UTC (permalink / raw)
To: 9fans
> One can convert between decimal and other bases (radices) using bc, by
> setting the input or output base:
Or, if you're on Unix, Eric Raymond suggests that the tool of choice
is his very own "ascii" [sic].
http://www.faqs.org/docs/artu/ch09s01.html#id2939746
"One indication that this program was a good idea is the fact that
it has an unexpected use — as a quick CLI aid to converting
between decimal, hex, octal, and binary representations of bytes."
Might be the best sentence in the book.
Russ
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 22:39 ` Russ Cox
@ 2004-04-11 22:55 ` Geoff Collyer
2004-04-12 0:01 ` Russ Cox
2004-04-12 2:35 ` boyd, rounin
2004-04-12 2:33 ` boyd, rounin
1 sibling, 2 replies; 67+ messages in thread
From: Geoff Collyer @ 2004-04-11 22:55 UTC (permalink / raw)
To: 9fans
On real Unix, one can use bc and adb. awk's printf would work too.
> "One indication that this program was a good idea is the fact that
> it has an unexpected use
s/ the fact//
Unexpected by whom? (I'm not a fan of Eric Raymond.)
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 22:55 ` Geoff Collyer
@ 2004-04-12 0:01 ` Russ Cox
2004-04-12 0:06 ` Geoff Collyer
2004-04-12 2:40 ` boyd, rounin
2004-04-12 2:35 ` boyd, rounin
1 sibling, 2 replies; 67+ messages in thread
From: Russ Cox @ 2004-04-12 0:01 UTC (permalink / raw)
To: 9fans
> s/ the fact//
> Unexpected by whom? (I'm not a fan of Eric Raymond.)
I think it's safe to say that using a character code display
program as a makeshift radix-converter is unexpected.
If you did the same trick with unicode(1), I wouldn't expect that!
On the other hand, awk is a programming language,
bc a calculator, and adb a debugger, all of which I'd
expect to be able to do radix conversions in.
I just find it amusing that this completely bizarre use
is proof that the program is a good idea. If it does
many things poorly, it must be a better tool than those
pesky programs that do only one thing well.
Russ
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-12 0:01 ` Russ Cox
@ 2004-04-12 0:06 ` Geoff Collyer
2004-04-12 0:22 ` Charles Forsyth
2004-04-12 2:42 ` boyd, rounin
2004-04-12 2:40 ` boyd, rounin
1 sibling, 2 replies; 67+ messages in thread
From: Geoff Collyer @ 2004-04-12 0:06 UTC (permalink / raw)
To: 9fans
I think he's latching onto a comment, probably in Software Tools, that
one measure of a good tool is that people find uses for it other than
those anticipated by its author(s). But, yes, it first has to be a
sharp tool that does one thing well.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-12 0:06 ` Geoff Collyer
@ 2004-04-12 0:22 ` Charles Forsyth
2004-04-12 2:42 ` boyd, rounin
1 sibling, 0 replies; 67+ messages in thread
From: Charles Forsyth @ 2004-04-12 0:22 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 791 bytes --]
i think it's also important that the unexpected use be one that
applies the program in its proper function, just in a way not anticipated
by the original design. indeed, that seems to be the whole point!
it's not just using a screwdriver to pry open a tin!
for instance, the traditional example of the pipeline for spelling checking application applies
several commands in turn in a way that is perfectly reasonable, and understandable,
but the composition to do spelling checking was not anticipated by those who wrote
the commands. in that pipeline in Software Tools, concat concatenates files,
translit does its normal transliteration, sort sorts, unique eliminates duplicates,
and `common' compares lines from two files as usual, but in this case one file is a dictionary.
[-- Attachment #2: Type: message/rfc822, Size: 1839 bytes --]
From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] german keymap
Date: Sun, 11 Apr 2004 17:06:06 -0700
Message-ID: <d732df90deca6fe59d78050a7b1c7c24@collyer.net>
I think he's latching onto a comment, probably in Software Tools, that
one measure of a good tool is that people find uses for it other than
those anticipated by its author(s). But, yes, it first has to be a
sharp tool that does one thing well.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 22:39 ` Russ Cox
2004-04-11 22:55 ` Geoff Collyer
@ 2004-04-12 2:33 ` boyd, rounin
1 sibling, 0 replies; 67+ messages in thread
From: boyd, rounin @ 2004-04-12 2:33 UTC (permalink / raw)
To: 9fans
dc is your friend.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 22:55 ` Geoff Collyer
2004-04-12 0:01 ` Russ Cox
@ 2004-04-12 2:35 ` boyd, rounin
1 sibling, 0 replies; 67+ messages in thread
From: boyd, rounin @ 2004-04-12 2:35 UTC (permalink / raw)
To: 9fans
> Unexpected by whom? (I'm not a fan of Eric Raymond.)
neither am i.
as james brown said::
talkin' loud 'n sayin' nothin'
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-12 0:01 ` Russ Cox
2004-04-12 0:06 ` Geoff Collyer
@ 2004-04-12 2:40 ` boyd, rounin
1 sibling, 0 replies; 67+ messages in thread
From: boyd, rounin @ 2004-04-12 2:40 UTC (permalink / raw)
To: 9fans
> On the other hand, awk is a programming language,
> bc a calculator, and adb a debugger, all of which I'd
> expect to be able to do radix conversions in.
i've never used 'bc', but awk and adb are brilliant pieces of work.
anyone ever tracked the 11/780 kernel stack from the LA-120 crash dump?
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-12 0:06 ` Geoff Collyer
2004-04-12 0:22 ` Charles Forsyth
@ 2004-04-12 2:42 ` boyd, rounin
2004-04-12 2:57 ` countryjoe
1 sibling, 1 reply; 67+ messages in thread
From: boyd, rounin @ 2004-04-12 2:42 UTC (permalink / raw)
To: 9fans
>...But, yes, it first has to be a sharp tool that does one thing well.
je suis completement d'accord.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-12 2:42 ` boyd, rounin
@ 2004-04-12 2:57 ` countryjoe
2004-04-12 4:02 ` boyd, rounin
0 siblings, 1 reply; 67+ messages in thread
From: countryjoe @ 2004-04-12 2:57 UTC (permalink / raw)
To: 9fans
Complètement....parceque sans l'accent ce n'est pas good.
Just teasing...!
Philippe
boyd, rounin wrote:
>>...But, yes, it first has to be a sharp tool that does one thing well.
>
>
> je suis completement d'accord.
>
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-12 2:57 ` countryjoe
@ 2004-04-12 4:02 ` boyd, rounin
0 siblings, 0 replies; 67+ messages in thread
From: boyd, rounin @ 2004-04-12 4:02 UTC (permalink / raw)
To: 9fans
ouais, la langue écrite est un cachemare :(
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-11 22:10 ` Geoff Collyer
2004-04-11 22:39 ` Russ Cox
@ 2004-04-21 17:43 ` rog
2004-04-21 17:44 ` boyd, rounin
` (2 more replies)
1 sibling, 3 replies; 67+ messages in thread
From: rog @ 2004-04-21 17:43 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]
> One can convert between decimal and other bases (radices) using bc, by
> setting the input or output base:
[...]
> For more general radix conversion, I use db:
to add my own 2 cents, i tend to use a little command-line
calculator i wrote ages ago to do this sort of thing.
i still prefer it to the above tools because it's not interactive
(= less stuff to type to get the results).
it's a reverse polish calculator, which works quite well
on the command line, as there's almost no punctuation
to get in the way of the shell's syntax (no brackets, and the
stuff to be executed is just a list of operands/operators, which
maps well to rc's lists). it's also handy for building up an expression
incrementally.
it's very similar to the inferno version, documented at
http://www.vitanuova.com/inferno/man/1/fc.html
all calculations are done in floating point, and it's a convenient
command-line way of getting access to the floating point
library, not to mention converting between bases.
e.g.
% fc 0x400
1024
% fc -x 1024
0x400
% fc 0400
256
% fc -x 0400
0x100
% fc 22 7 /
3.142857143
% x=(1 2 3 4 5 6)
% fc $x sum
21
% fc -B 96451234
0b00000101101111111011101010100010
10987654321098765432109876543210
3 2 1
% fc 0b00000101101111111011101010100010 sqrt
9820.958914
% fc -help
Usage: fc -[dcxotbB] <postfix expression>
Option specifies output format:
-d decimal
-c rune
-x hex
-o octal
-t time
-b binary
-B annotated binary
Operands are decimal(default), hex(0x), octal(0), binary(0b),
rune(@), time(hh:mm.ss)
Operators are: (number of arguments in brackets)
swap[2] dup[1] rep[n] ![1] %[2] p[1] *,×,x[2] **,xx,^,pow[2]
+[2] -[2] /[2] _[1] <<,«,shl[2] >>,»,shr[2] and,⋀[2] ⋁,or[2]
xor[2] not[1] sum[n] acos[1] asin[1] atan[1] atan2[2] ceil[1]
cos[1] cosh[1] deg[1] exp[1] fabs[1] floor[1] fmod[2] ldexp[2]
log,ln[1] log10[1] log2[1] rad[1] sin[1] sinh[1] √,sqrt[1]
tan[1] tanh[1] trunc[2]
Constants are:
π=3.14159
pi=3.14159
e=2.71828
%
i've attached it. someone might find it useful.
[-- Attachment #2: fc.c.gz --]
[-- Type: application/octet-stream, Size: 4157 bytes --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 17:43 ` rog
@ 2004-04-21 17:44 ` boyd, rounin
2004-04-21 17:56 ` rog
2004-04-21 21:26 ` [9fans] an idea rog
2004-04-22 1:57 ` [9fans] german keymap Michael Jeffrey
2 siblings, 1 reply; 67+ messages in thread
From: boyd, rounin @ 2004-04-21 17:44 UTC (permalink / raw)
To: 9fans
> to add my own 2 cents, i tend to use a little command-line
> calculator i wrote ages ago to do this sort of thing.
why?
dc(1)
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 17:44 ` boyd, rounin
@ 2004-04-21 17:56 ` rog
2004-04-21 18:03 ` boyd, rounin
0 siblings, 1 reply; 67+ messages in thread
From: rog @ 2004-04-21 17:56 UTC (permalink / raw)
To: 9fans
> why?
>
> dc(1)
dc doesn't take arguments on the command line.
dc doesn't do stuff in floating point.
dc doesn't gives you access to the floating point operators.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 17:56 ` rog
@ 2004-04-21 18:03 ` boyd, rounin
2004-04-21 18:41 ` rog
0 siblings, 1 reply; 67+ messages in thread
From: boyd, rounin @ 2004-04-21 18:03 UTC (permalink / raw)
To: 9fans
> dc doesn't take arguments on the command line.
echo ... | dc
> dc doesn't do stuff in floating point.
% dc
5k 1 3/p
.33333
2vp
1.41421
> dc doesn't gives you access to the floating point operators.
and which set would you like?
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 18:03 ` boyd, rounin
@ 2004-04-21 18:41 ` rog
2004-04-21 18:42 ` Rob Pike
` (2 more replies)
0 siblings, 3 replies; 67+ messages in thread
From: rog @ 2004-04-21 18:41 UTC (permalink / raw)
To: 9fans
> > dc doesn't take arguments on the command line.
>
> echo ... | dc
% echo 5k 1 3 /p|dc
.33333
isn't nearly as convenient as:
% fc 1 3 /
0.3333333333
especially since in rio i can just tack on " 60 +" to the end of that
line, click Send and thus manipulate the original expression with
minimal effort.
yes, i know they're more-or-less equivalent (but see below), but i
thought i'd mention it because since i wrote it i've found that it's
one of those tools that just "fits" really nicely. no particular
feature in mind; i just find it consistently satisfying to use. YMMV,
of course; i'll freely admit i'm biased :-)
> % dc
> 5k 1 3/p
> .33333
> 2vp
> 1.41421
i said *floating* point.
> > dc doesn't gives you access to the floating point operators.
>
> and which set would you like?
the set available by including libc.h, or some approximation thereof
(e.g. sin, log, sqrt, etc).
i presume hoc gives access to these also, but it's overkill for the
kind of thing i'm talking about, not to mention awkward to use on the
command line.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 18:41 ` rog
@ 2004-04-21 18:42 ` Rob Pike
2004-04-21 19:16 ` rog
2004-04-21 18:43 ` boyd, rounin
2004-04-21 18:47 ` boyd, rounin
2 siblings, 1 reply; 67+ messages in thread
From: Rob Pike @ 2004-04-21 18:42 UTC (permalink / raw)
To: 9fans
> i presume hoc gives access to these also, but it's overkill for the
> kind of thing i'm talking about, not to mention awkward to use on the
> command line.
% hoc -e 1/3
.333333333333
%
how hard was that?
-rob
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 18:41 ` rog
2004-04-21 18:42 ` Rob Pike
@ 2004-04-21 18:43 ` boyd, rounin
2004-04-21 18:47 ` boyd, rounin
2 siblings, 0 replies; 67+ messages in thread
From: boyd, rounin @ 2004-04-21 18:43 UTC (permalink / raw)
To: 9fans
> isn't nearly as convenient as:
> % fc 1 3 /
> 0.3333333333
ever written a script?
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 18:41 ` rog
2004-04-21 18:42 ` Rob Pike
2004-04-21 18:43 ` boyd, rounin
@ 2004-04-21 18:47 ` boyd, rounin
2004-04-21 18:57 ` Rob Pike
2 siblings, 1 reply; 67+ messages in thread
From: boyd, rounin @ 2004-04-21 18:47 UTC (permalink / raw)
To: 9fans
> i said *floating* point.
1.23456789 2.3456789 20k*p
2.895899850190521
> > and which set would you like?
>
> the set available by including libc.h, or some approximation thereof
> (e.g. sin, log, sqrt, etc).
err, awk(1)?
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 18:47 ` boyd, rounin
@ 2004-04-21 18:57 ` Rob Pike
2004-04-21 18:58 ` boyd, rounin
0 siblings, 1 reply; 67+ messages in thread
From: Rob Pike @ 2004-04-21 18:57 UTC (permalink / raw)
To: 9fans
> > i said *floating* point.
>
> 1.23456789 2.3456789 20k*p
> 2.895899850190521
>
boyd, he said floating point.
% dc
10 300 ^ p
100000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000
% hoc -e '10^300'
1e+300
%
-rob
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 18:57 ` Rob Pike
@ 2004-04-21 18:58 ` boyd, rounin
2004-04-21 19:20 ` rog
0 siblings, 1 reply; 67+ messages in thread
From: boyd, rounin @ 2004-04-21 18:58 UTC (permalink / raw)
To: 9fans
> boyd, he said floating point.
i was hoping he could join-the-dots.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 18:42 ` Rob Pike
@ 2004-04-21 19:16 ` rog
0 siblings, 0 replies; 67+ messages in thread
From: rog @ 2004-04-21 19:16 UTC (permalink / raw)
To: 9fans
> how hard was that?
i find the reverse-polish thing works really nicely on the command line.
whatever the complexity of the expression, you can always
add stuff to the end to operate on the previous result.
the output is always suitable as input.
if i've got some values in shell variables, the fact that you
don't have to quote is really nice:
% v=4000
% fc $v log 2 log /
12
%
vs.
% v=4000
% hoc -e 'log('$v')/log(2)'
11.96578428466
%
it's also pleasant to be able to operate on lists of values.
e.g. multiply a list of of numbers together:
% d=(3.4 5.6 3.9 99)
% fc $d x rep
7351.344
%
neither awk nor hoc have anything like the complete set of math
functions provided in libc.h. it's useful having these if you're
experimenting with a mathematical expression in a program
and want to know what the result is without compiling a program to do it.
nor does hoc convert between bases, which is what prompted this whole
discussion.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 18:58 ` boyd, rounin
@ 2004-04-21 19:20 ` rog
2004-04-21 19:58 ` boyd, rounin
0 siblings, 1 reply; 67+ messages in thread
From: rog @ 2004-04-21 19:20 UTC (permalink / raw)
To: 9fans
> i was hoping he could join-the-dots.
"the dots" in this case mean that you have to
pre-guess the scale of the result of the expression
before running it.
a useful skill if you're using log tables, but
not really something that's ideal for casual
use.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 19:20 ` rog
@ 2004-04-21 19:58 ` boyd, rounin
2004-04-21 20:26 ` rog
0 siblings, 1 reply; 67+ messages in thread
From: boyd, rounin @ 2004-04-21 19:58 UTC (permalink / raw)
To: 9fans
> "the dots" in this case mean that you have to
> pre-guess the scale of the result of the expression
> before running it.
no, 'the dots' is that someone has already done the hard
work [dc/awk] and you should build a tool with these
extremely well tested tools, rather than building yet
another one that leaves itself open to be choc-full-o-bugs.
pre-guess the scale? if you don't like it the first time snarf
it up, change the scale and run it again. eg. get it to spit:
dc input etc = result [programing the inputs].
before you make the calculation i think you'd have a pretty
good idea of how 'big' the result will be. or, if you want to
write more code, write a thing to scale the output, based
on a huge input scale.
this is not large-n-bit RSA.
% set roman
btw: i think i shall return to my 243 mega parsec barns of red.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 19:58 ` boyd, rounin
@ 2004-04-21 20:26 ` rog
0 siblings, 0 replies; 67+ messages in thread
From: rog @ 2004-04-21 20:26 UTC (permalink / raw)
To: 9fans
> before you make the calculation i think you'd have a pretty
> good idea of how 'big' the result will be.
not good enough.
the scale of sub-expressions is important too.
> or, if you want to
> write more code, write a thing to scale the output, based
> on a huge input scale.
there's already something that does this, to a good approximation.
it's called the FPU.
> rather than building yet
> another one that leaves itself open to be choc-full-o-bugs.
i wrote it nearly 15 years ago.
it's almost trivially simple. (ok, it gained a couple of excrescences
early on, but i knocked 'em off for the inferno version).
i just pointed it out because it's one of the very few
tools i've written that i've found consistently useful
and usable. if you don't like the way it works, ignore it.
i really don't see the problem.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [9fans] an idea
2004-04-21 17:43 ` rog
2004-04-21 17:44 ` boyd, rounin
@ 2004-04-21 21:26 ` rog
2004-04-26 7:57 ` Fco.J.Ballesteros
2004-04-26 15:12 ` Russ Cox
2004-04-22 1:57 ` [9fans] german keymap Michael Jeffrey
2 siblings, 2 replies; 67+ messages in thread
From: rog @ 2004-04-21 21:26 UTC (permalink / raw)
To: 9fans
ok, this idea's a bit off the wall, but i thought i'd mention it
because i think it's got some potential.
some observations on the way 9p works currently:
1) if i import a remote namespace containing /srv, mounting a file in
/srv triples the latency of requests on the mounted namespace (write
tmsg, reply, read rmsg header, reply, read rmsg body, reply).
2) without re-mounting the connection, there's no way of introducing a
new user to a remotely imported namespace.
3) the '#' namespace is quite restrictive (devices can't be attached by
a remote machine, unless using an additional protocol, such as
import), but also overly permissive (there's no way of arbitrarily
restricting the set of devices available to sub-processes)
4) there's an arbitrary distinction between the '#' namespace and normal
namespace, when kernel/user boundary is potentially largely arbitrary.
you can't, for instance, substitute a user-level simulation of device
x if a program accesses it via #x rather than a previously mounted
instance of it.
5) there's a global idea of "user" (the user id of the current
process, as used by fauth(2) at al) but in a situation with resources
imported from many authentication domains, this isn't necessarily
realistic.
6) kernel level devices are privileged in that they can access some
user resources directly, in particular open fds and names. user level
servers can't.
here's the germ of a solution: put auth files in the namespace.
here's how it might work:
in your namespace you find a file with the DMAUTH bit set, an auth
file. opening this produces a fid suitable for authentication, which
can also be used as part of a later attach message, giving access to a
new namespace - the namespace accessible as a result of this attach is
distinct (files occupy a different qid space) but derived (the server
decides what namespace to provide from the auth file used).
imagine that /srv contains a load of these auth files. each one is
like a gateway into a new namespace, in just the same way that the
files in the current /srv are, except that the mount driver's job has
already been done, so that someone mounting one of these remotely does
not incur any additional latency over the network.
moreover (and this is where things start to become interesting, i
think), there's no particular reason why the auth files in /srv have
to be 9p servers - they could be devices too.
suppose, for the sake of argument, that it is possible to have a file
descriptor that represents a walked-to-but-not-yet-open file (the
kernel can do this already; an implementation would be trivial).
suppose also that there are some of the usual 9p-like operations on
such a file, such as walk, bind, open, etc.
then imagine a device similar to the current /srv, except that any
attach gives a new, clean instance, containing nothing at all, rather
than globally shared resources, as currently. any file descriptor
could be posted to this directory; a walk to it would give you back
the original.
when you boot the system, you bootstrap an instance of the /srv
device, containing an auth file for each device compiled into the
kernel, including the srv device itself.
suddenly you don't need the '#' namespace any more.
to do the equivalent of newns, attach to a new instance of the srv
device, place within it the resources you want available after the
newns (could include auth files, directories, etc), clear the
namespace, and then bind the new instance of /srv (you'll still have
its file descriptor around) onto /.
for a subprocess, you can arrange exactly the set of devices that are
available. there's also the potential to "push" an authentication
scheme onto an auth file. in fact there are bucketloads of
possibilities i haven't begun to think about yet.
this kind of arrangement seems to me to make the namespace less
arbitrary and more powerful. an auth file acts as a kind of tunnel to
another namespace, but one that itself exists within the namespace,
and is thus amenable to "meta-" namespace tools, such as iostats, cfs,
etc.
the implementation would be straightforward (main kernel change would
be having a Dev* inside a Chan rather than indirecting through
devtab), and it doesn't change 9p. almost all user-level code would
be unaffected.
quite a number of solutions to previously unpleasant problems seem to
me to fall out from this, but i'm likely missing some blindingly
obvious objection.
what do you think?
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] german keymap
2004-04-21 17:43 ` rog
2004-04-21 17:44 ` boyd, rounin
2004-04-21 21:26 ` [9fans] an idea rog
@ 2004-04-22 1:57 ` Michael Jeffrey
2 siblings, 0 replies; 67+ messages in thread
From: Michael Jeffrey @ 2004-04-22 1:57 UTC (permalink / raw)
To: 9fans
----- Original Message -----
From: <rog@vitanuova.com>
To: <9fans@cse.psu.edu>
Sent: Wednesday, April 21, 2004 10:43 AM
Subject: Re: [9fans] german keymap
> it's a reverse polish calculator, which works quite well
The first calculator I bought was from a market stall. The
stall holder said he was selling them cheap because "they
don't have an '=' key"; turned out it used reverse polish.
It did work quite well, and no one wanted
to borrow it either.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-21 21:26 ` [9fans] an idea rog
@ 2004-04-26 7:57 ` Fco.J.Ballesteros
2004-04-26 8:04 ` Charles Forsyth
` (2 more replies)
2004-04-26 15:12 ` Russ Cox
1 sibling, 3 replies; 67+ messages in thread
From: Fco.J.Ballesteros @ 2004-04-26 7:57 UTC (permalink / raw)
To: 9fans
> 1) if i import a remote namespace containing /srv, mounting a file in
> /srv triples the latency of requests on the mounted namespace (write
> tmsg, reply, read rmsg header, reply, read rmsg body, reply).
> 2) without re-mounting the connection, there's no way of introducing a
> new user to a remotely imported namespace.
But this could be done by arranging the the final clients to talk to the
actual servers, without resorting to proxy places. But this would require
changing the name space semantics. We do that for Plan B, but don't know
how it would fit with Plan 9. To make it more clear what I mean,
one way to do it would be to make all 9P servers become network addressable,
then change the way the ns is printed so that a user could reproduce the
ns from any other place in the network.
> 3) the '#' namespace is quite restrictive (devices can't be attached by
> a remote machine, unless using an additional protocol, such as
> import), but also overly permissive (there's no way of arbitrarily
> restricting the set of devices available to sub-processes)
>
> 4) there's an arbitrary distinction between the '#' namespace and normal
> namespace, when kernel/user boundary is potentially largely arbitrary.
> you can't, for instance, substitute a user-level simulation of device
> x if a program accesses it via #x rather than a previously mounted
> instance of it.
A regular /dev (or whatever) directory with
one mounted file|dir per device would be cleaner. Instead of doing the
#s trick, newns() could return not a clean namespace, but one with
devices installed. To do sandboxing one could unmount from there whatever
is not wanted.
> 6) kernel level devices are privileged in that they can access some
> user resources directly, in particular open fds and names. user level
> servers can't.
This is one thing that I dislike even with the way things work today. But
it would probably require changing many interfaces. The clone interface
is something that I think is confussing.
> here's the germ of a solution: put auth files in the namespace.
BTW, I don't see why you would need this:
> the implementation would be straightforward (main kernel change would
> be having a Dev* inside a Chan rather than indirecting through
> devtab), and it doesn't change 9p. almost all user-level code would
> be unaffected.
Is it to proxy for a remote dev?
PS: I had your mail hanging around since you sent it, it's just that it was not
clear for me how your idea would actually work when compared, for example,
with what I suggested above or with the current behaviour. That's why I
didn't reply earlier. Perhaps the same happen to others.
cheers
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 7:57 ` Fco.J.Ballesteros
@ 2004-04-26 8:04 ` Charles Forsyth
2004-04-26 8:10 ` Fco.J.Ballesteros
2004-04-26 16:41 ` rog
2004-04-27 1:44 ` Scott Schwartz
2 siblings, 1 reply; 67+ messages in thread
From: Charles Forsyth @ 2004-04-26 8:04 UTC (permalink / raw)
To: 9fans
> 6) kernel level devices are privileged in that they can access some
>>This is one thing that I dislike even with the way things work today. But
>>it would probably require changing many interfaces. The clone interface
>>is something that I think is confussing.
user level file devices can and do implement clone files/directories
without special rights, so i'm not sure that comment
is in the right place (discussing kernel devices).
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 8:04 ` Charles Forsyth
@ 2004-04-26 8:10 ` Fco.J.Ballesteros
2004-04-26 8:13 ` Charles Forsyth
0 siblings, 1 reply; 67+ messages in thread
From: Fco.J.Ballesteros @ 2004-04-26 8:10 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 43 bytes --]
Agree. It's not in the right place.
Sorry.
[-- Attachment #2: Type: message/rfc822, Size: 2098 bytes --]
From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] an idea
Date: Mon, 26 Apr 2004 09:04:23 +0100
Message-ID: <8a6a3792c064eb1febf21077afc2b938@terzarima.net>
> 6) kernel level devices are privileged in that they can access some
>>This is one thing that I dislike even with the way things work today. But
>>it would probably require changing many interfaces. The clone interface
>>is something that I think is confussing.
user level file devices can and do implement clone files/directories
without special rights, so i'm not sure that comment
is in the right place (discussing kernel devices).
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 8:10 ` Fco.J.Ballesteros
@ 2004-04-26 8:13 ` Charles Forsyth
0 siblings, 0 replies; 67+ messages in thread
From: Charles Forsyth @ 2004-04-26 8:13 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 57 bytes --]
i was really just checking that i hadn't misunderstood!
[-- Attachment #2: Type: message/rfc822, Size: 4094 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 43 bytes --]
Agree. It's not in the right place.
Sorry.
[-- Attachment #2.1.2: Type: message/rfc822, Size: 2098 bytes --]
From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] an idea
Date: Mon, 26 Apr 2004 09:04:23 +0100
Message-ID: <8a6a3792c064eb1febf21077afc2b938@terzarima.net>
> 6) kernel level devices are privileged in that they can access some
>>This is one thing that I dislike even with the way things work today. But
>>it would probably require changing many interfaces. The clone interface
>>is something that I think is confussing.
user level file devices can and do implement clone files/directories
without special rights, so i'm not sure that comment
is in the right place (discussing kernel devices).
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-21 21:26 ` [9fans] an idea rog
2004-04-26 7:57 ` Fco.J.Ballesteros
@ 2004-04-26 15:12 ` Russ Cox
2004-04-26 15:49 ` ron minnich
2004-04-26 18:09 ` rog
1 sibling, 2 replies; 67+ messages in thread
From: Russ Cox @ 2004-04-26 15:12 UTC (permalink / raw)
To: 9fans
Here's an independent but seemingly similar idea.
Suppose the kernel were a good 9P multiplexor instead
of a cleaner Unix kernel with devmnt hanging on the side.
All the devices would speak in terms of 9P messages (something
like Fcall or lib9p's Req, not the wire representation). The
traditional system calls open, read, write, etc. would simply
translate into the obvious 9P transactions, always. Devmnt's
job then is only to read/write messages from fds.
With 9P messages at the center, exportfs is trivial -- the kernel
would need to rewrite tags and fids in the messages on
their way to the appropriate 9P server. Suppose also that the
kernel was smart about mounting a channel it exports, noticing
this case and avoiding the extra packs and unpacks to and
from wire representation. Then fd = exportfs("/a"); mount(fd, "/b", MREPL);
would be equivalent to bind("/a", "/b", MREPL) as far as message
efficiency is concerned -- in neither case would accesses to /b be
any different (in terms of extra wire traffic over pipes) than
access to /a.
Now suppose /srv could only post 9P services, meaning that when
multiple people opened the same service, the kernel would take
care of multiplexing their 9P requests appropriately so that the
original poster would only see a single logical 9P conversation.
Then there's no difference between mounting a fd somewhere
and opening that same fd and doing your own 9P traffic on it
via read and write. (You can't do that right now because once
a fd gets mounted, r/w from user-space would not get multiplexed
properly.)
Now the # names can go away too -- the kernel just starts
by posting all its devices in /srv.
Of course, this says nothing about auth files, much less authentication.
I think that your scheme uses auth files the same way mine does
9P services. Put another way, I think (and I could be way off base
here) that your scheme posts unauthenticated 9P services while
mine posts preauthenticated 9P services.
I don't see how to do authentication in user space and keep the
"reductions" of things like fd = exportfs("/a"); mount(fd, "/b", MREPL);.
It might be that on the local machine people are already authenticated
"enough", but I don't see what to do to serve incoming network
connections.
I think some of the things you brought up are independent of
either scheme. For example, having a file descriptor represent
an unopened file and bootstrapping newns by setting up a name
space in a subtree and binding onto / could be done now without
any significant kernel changes.
What I don't really understand about your scheme is how much
you're getting from an auth file being authentication-related and
how much you're getting from it being the beginning of a 9P
connection.
I do think there's a germ of a good idea here, but the devil
is in the details.
Russ
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 15:12 ` Russ Cox
@ 2004-04-26 15:49 ` ron minnich
2004-04-26 16:42 ` rog
2004-04-26 16:59 ` Russ Cox
2004-04-26 18:09 ` rog
1 sibling, 2 replies; 67+ messages in thread
From: ron minnich @ 2004-04-26 15:49 UTC (permalink / raw)
To: 9fans
These are neat ideas but there is one thing I still like about '#' -- it
distinguishes what for me is non-private stuff from private stuff. I.e. in
my (probably too simplistic) way of thinking, all the '#' stuff in
addition to being devices means 'if bound in a name space, it's common to
all'. If all the # stuff becomes things in /srv we'll lost the distinction
-- it could be that it doesn't really matter, though.
ron
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 7:57 ` Fco.J.Ballesteros
2004-04-26 8:04 ` Charles Forsyth
@ 2004-04-26 16:41 ` rog
2004-04-26 16:43 ` Charles Forsyth
2004-04-26 16:48 ` Fco.J.Ballesteros
2004-04-27 1:44 ` Scott Schwartz
2 siblings, 2 replies; 67+ messages in thread
From: rog @ 2004-04-26 16:41 UTC (permalink / raw)
To: 9fans
> one way to do it would be to make all 9P servers become network addressable
this is not possible in general.
one of the beauties of 9p is the fact that it is completely transport
independent - just so long as you've got that single channel
(whatever it's over), you've got access to the capabilities
at the other end.
there is not, and neither can there be, a general addressing protocol.
hence it makes sense, i think, to have a protocol that can encapsulate
the idea of introducing new users *within* a namespace.
> A regular /dev (or whatever) directory with
> one mounted file|dir per device would be cleaner. Instead of doing the
> #s trick, newns() could return not a clean namespace, but one with
> devices installed. To do sandboxing one could unmount from there whatever
> is not wanted.
how would newns() (which is not a system call) get access to those
devices? and if a process is in a sandbox, what's to stop
it doing a newns() and getting access to those devices anyway.
the srv device idea is to let the available devices percolate down
from the top level. there's no way to access a device to
which one has not been granted access.
> This is one thing that I dislike even with the way things work today. But
> it would probably require changing many interfaces.
i think it's actually relatively straightforward to change this.
i don't believe this capability is used in many places,
and the number of kernel devices that use it is limited.
a simple capability scheme should do the job.
> BTW, I don't see why you would need this:
>
> > the implementation would be straightforward (main kernel change would
> > be having a Dev* inside a Chan rather than indirecting through
> > devtab), and it doesn't change 9p. almost all user-level code would
> > be unaffected.
>
> Is it to proxy for a remote dev?
you're right, i don't think it is necessary. i'd thought it was
required due to the way that some kernel devices (in particular the
srv device) would "gateway" through to other kernel devices.
i think the current interface is almost sufficient (depending
on what kind of authentication might be required by kernel devices).
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 15:49 ` ron minnich
@ 2004-04-26 16:42 ` rog
2004-04-26 16:59 ` Russ Cox
1 sibling, 0 replies; 67+ messages in thread
From: rog @ 2004-04-26 16:42 UTC (permalink / raw)
To: 9fans
> These are neat ideas but there is one thing I still like about '#' -- it
> distinguishes what for me is non-private stuff from private stuff.
the devtype letter would still work, which should be sufficient.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 16:41 ` rog
@ 2004-04-26 16:43 ` Charles Forsyth
2004-04-26 16:57 ` rog
2004-04-26 16:48 ` Fco.J.Ballesteros
1 sibling, 1 reply; 67+ messages in thread
From: Charles Forsyth @ 2004-04-26 16:43 UTC (permalink / raw)
To: 9fans
>>a simple capability scheme should do the job.
the thing that applies the capability must be in the kernel to
affect kernel-related data, so i'm not sure it's very different in
practice from a driver doing the same.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 16:41 ` rog
2004-04-26 16:43 ` Charles Forsyth
@ 2004-04-26 16:48 ` Fco.J.Ballesteros
1 sibling, 0 replies; 67+ messages in thread
From: Fco.J.Ballesteros @ 2004-04-26 16:48 UTC (permalink / raw)
To: 9fans
> one of the beauties of 9p is the fact that it is completely transport
> independent - just so long as you've got that single channel
> (whatever it's over), you've got access to the capabilities
> at the other end.
I know, and that's also why in general you can't reproduce a ns at
a remote location. However, if you make all your servers responsive at
a network address, you are one step closer to do that.
> hence it makes sense, i think, to have a protocol that can encapsulate
> the idea of introducing new users *within* a namespace.
Your point makes sense to me. But I think it's not too radical to solve
the (few) problems that bother me while using plan 9. The one I mention
above is one of them. My argument is that if we ever get into changing
the name space, I'd try to fix some other problems too.
>> A regular /dev (or whatever) directory with
>> one mounted file|dir per device would be cleaner. Instead of doing the
>> #s trick, newns() could return not a clean namespace, but one with
>> devices installed. To do sandboxing one could unmount from there whatever
>> is not wanted.
>
> how would newns() (which is not a system call) get access to those
> devices? and if a process is in a sandbox, what's to stop
> it doing a newns() and getting access to those devices anyway.
Sorry, by newns() I meant rfork(RFCNAMEG). It can access them because it's
the kernel.
Also, RFNOMNT would prevent your sandbox to break.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 16:43 ` Charles Forsyth
@ 2004-04-26 16:57 ` rog
0 siblings, 0 replies; 67+ messages in thread
From: rog @ 2004-04-26 16:57 UTC (permalink / raw)
To: 9fans
> the thing that applies the capability must be in the kernel to
> affect kernel-related data, so i'm not sure it's very different in
> practice from a driver doing the same.
you need one system call to allow a process to translate from local
capability (fd) to external capability (a string). that can't be
implemented in the namespace itself because the namespace might not be
implemented locally (for instance things can still work correctly if
iostats is mediating the entire namespace).
the translation the other way (from capability to fd) can, and should,
be implemented by a kernel device.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 15:49 ` ron minnich
2004-04-26 16:42 ` rog
@ 2004-04-26 16:59 ` Russ Cox
2004-04-26 17:05 ` Charles Forsyth
1 sibling, 1 reply; 67+ messages in thread
From: Russ Cox @ 2004-04-26 16:59 UTC (permalink / raw)
To: 9fans
> These are neat ideas but there is one thing I still like about '#' -- it
> distinguishes what for me is non-private stuff from private stuff. I.e. in
> my (probably too simplistic) way of thinking, all the '#' stuff in
> addition to being devices means 'if bound in a name space, it's common to
> all'. If all the # stuff becomes things in /srv we'll lost the distinction
no it doesn't. #d. #c/user. etc.
i think what you're really getting at is that # always
means what you want it to mean and not what your
parent process set it up to mean. and yes, there is
a tension between really getting the recursion right
and being able to do this. but a convention that
/srv/sharp was always the root of the name space
would be enough. even now, #p doesn't always
means the process table. sometimes it means
"you're running RFNOMT -- go away."
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 16:59 ` Russ Cox
@ 2004-04-26 17:05 ` Charles Forsyth
2004-04-26 18:04 ` Philippe Anel
0 siblings, 1 reply; 67+ messages in thread
From: Charles Forsyth @ 2004-04-26 17:05 UTC (permalink / raw)
To: 9fans
>>would be enough. even now, #p doesn't always
>>means the process table. sometimes it means
>>"you're running RFNOMT -- go away."
that one is currently one of the `iffy' amongst the exceptions
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 17:05 ` Charles Forsyth
@ 2004-04-26 18:04 ` Philippe Anel
2004-04-26 18:16 ` rog
2004-04-26 18:20 ` rog
0 siblings, 2 replies; 67+ messages in thread
From: Philippe Anel @ 2004-04-26 18:04 UTC (permalink / raw)
To: 9fans
At 19:05 26/04/04, you wrote:
> >>would be enough. even now, #p doesn't always
> >>means the process table. sometimes it means
> >>"you're running RFNOMT -- go away."
>
>that one is currently one of the `iffy' amongst the exceptions
With /srv/sharp, can these exceptions in 'chan.c:namec()' be treated
with a file flag ?
Philippe,
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 15:12 ` Russ Cox
2004-04-26 15:49 ` ron minnich
@ 2004-04-26 18:09 ` rog
2004-04-26 18:44 ` [9fans] local 9p multiplexing Russ Cox
` (3 more replies)
1 sibling, 4 replies; 67+ messages in thread
From: rog @ 2004-04-26 18:09 UTC (permalink / raw)
To: 9fans
> Now suppose /srv could only post 9P services, meaning that when
> multiple people opened the same service, the kernel would take
> care of multiplexing their 9P requests appropriately so that the
> original poster would only see a single logical 9P conversation.
this, presumably, would mean that the kernel would have to know about
srv files, and translate all reads and writes through them as 9p
messages (after all there's no guarantee that something posted into
/srv, although a 9p service, has been either mounted or exported on
the local machine, and we need to multiplex reads correctly).
ok, so we assume a kernel knows about srv files.
it could know by looking at the device letter, or by a mode bit in the
file. let's assume the latter, as it's more general (and reducible to
the former).
say we've imported a namespace from a remote machine. in the
namespace is a /srv directory, containing various exported 9p
services. we wish to mount one of them.
how can we do that without adding latency? even if the local kernel
knows that the remote file represents a 9p connection, how can it
actually transfer data to and from that connection?
the 9p messages directed to that connection must be in-band with the
9p messages from the original connection - the only alternative is to
use Twrite and Tread messages, which adds latency.
that implies that all those messages must have valid tags, fids, etc.
but where have those fids come from?
you need something to associate the old fid (open on the file in /srv)
with the new fid (representing the root of the new hierarchy).
i can't see how your scheme can cope with that.
> I don't see how to do authentication in user space and keep the
> "reductions" of things like fd = exportfs("/a"); mount(fd, "/b", MREPL);.
i'm not sure one needs to try.
i think you're maybe glossing over something here too.
one doesn't usually do the above, but actually:
exportfs(p[0], "/a"); mount(p[1], "/b", MREPL);
where p[0] and p[1] are two ends of a pipe.
presumably the kernel would have to know about the pipe
device as a special case?
> Suppose the kernel were a good 9P multiplexor instead
> of a cleaner Unix kernel with devmnt hanging on the side.
i think what i like least about this scheme is that you need lots of
extra processes... all of which are unnecessary.
one thing that's really nice about the current kernel scheme is that a
file operation at user level is just a function call in the kernel.
you already have the process context around, and that's what gets used.
if devices speak in terms of 9p messages, you're talking about a
stream of 9p messages. many processes write messages into the stream,
and then you need many processes at the other side to deal with the
concurrency (as exportfs does). you're dealing with a many-one-many
mapping, rather than the current simple one-one scheme, not to mention
the additional data copying, context switches and fid/tag counting.
> What I don't really understand about your scheme is how much
> you're getting from an auth file being authentication-related and
> how much you're getting from it being the beginning of a 9P
> connection.
it's crucial that you can do the authentication, as it allows a
service to multiplex several different users onto the same connection.
as charles likes to point out, the "important" authentication is the
kind that Styx uses - i.e. end to end. however, once you've
connected to a party you trust (to some extent) to act on your behalf,
it's still useful to be able to authenticate yourself to third parties
through them.
to some services the identity of the user doesn't matter. others rely
on it totally (for instance /proc).
i'm not sure exactly what form local authentication should take though.
[you can defer the decision though: suppose that all kernel
level devices believed whatever user was named in the attach message.
then imagine a device which, given an auth fd, produced another
auth fd that required the client to satisfy certain authentication criteria
- once satisfied, an attach would attach to the original device,
as the correct (and authenticated) user. in this way you could push
whatever authentication scheme you liked onto all the kernel devices
available in /srv]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 18:04 ` Philippe Anel
@ 2004-04-26 18:16 ` rog
2004-04-26 18:36 ` Philippe Anel
2004-04-26 18:20 ` rog
1 sibling, 1 reply; 67+ messages in thread
From: rog @ 2004-04-26 18:16 UTC (permalink / raw)
To: 9fans
> With /srv/sharp, can these exceptions in 'chan.c:namec()' be treated
> with a file flag ?
i'm not sure that /srv/sharp would be a great idea. after all, isn't
the idea of this to lose the distinction between user and kernel
devices, and to be able to arrange things arbitrarily for a given
process?
after all, it might be quite reasonable, in some circumstances, to
allow a process access to #S but deny it to #p.
in the scheme i'm thinking of, the exceptions in namec() would
go, along with RFNOMNT.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 18:04 ` Philippe Anel
2004-04-26 18:16 ` rog
@ 2004-04-26 18:20 ` rog
1 sibling, 0 replies; 67+ messages in thread
From: rog @ 2004-04-26 18:20 UTC (permalink / raw)
To: 9fans
actually, i think i read russ's email wrong.
i mistakenly thought he was referring to /srv/sharp
as a kind of "device containing all # devices" device.
if it's just a conventional place to get access to
the "original" root, that's ok... but i'm not sure it would
buy you much (just one extra thing to arrange in your ns file)
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 18:16 ` rog
@ 2004-04-26 18:36 ` Philippe Anel
2004-04-26 20:27 ` rog
2004-04-27 8:13 ` Fco.J.Ballesteros
0 siblings, 2 replies; 67+ messages in thread
From: Philippe Anel @ 2004-04-26 18:36 UTC (permalink / raw)
To: 9fans
At 20:16 26/04/04, you wrote:
> > With /srv/sharp, can these exceptions in 'chan.c:namec()' be treated
> > with a file flag ?
>
>i'm not sure that /srv/sharp would be a great idea. after all, isn't
>the idea of this to lose the distinction between user and kernel
>devices, and to be able to arrange things arbitrarily for a given
>process?
True. In the scheme i'm thinking off, there is no distinction between
user and kernel device. In fact, I'd like to move all the device to
user mode. But i still haven't find how to move #p or #s to user mode.
Finally i think that some device have to be kernel device.
In fact I'd like to build a kind of a microkernel without the task/thread
stuff, but entierly based on channels (ports) capabilities and 9p2000.
>after all, it might be quite reasonable, in some circumstances, to
>allow a process access to #S but deny it to #p.
I think capabilities would help here.
>in the scheme i'm thinking of, the exceptions in namec() would
>go, along with RFNOMNT.
Due to capabilities, in my scheme there is no need to have RFNOMNT too.
Philippe.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [9fans] local 9p multiplexing
2004-04-26 18:09 ` rog
@ 2004-04-26 18:44 ` Russ Cox
2004-04-26 18:54 ` [9fans] remote " Russ Cox
` (2 subsequent siblings)
3 siblings, 0 replies; 67+ messages in thread
From: Russ Cox @ 2004-04-26 18:44 UTC (permalink / raw)
To: 9fans
> > Now suppose /srv could only post 9P services, meaning that when
> > multiple people opened the same service, the kernel would take
> > care of multiplexing their 9P requests appropriately so that the
> > original poster would only see a single logical 9P conversation.
>
> this, presumably, would mean that the kernel would have to know about
> srv files, and translate all reads and writes through them as 9p
> messages (after all there's no guarantee that something posted into
> /srv, although a 9p service, has been either mounted or exported on
> the local machine, and we need to multiplex reads correctly).
this is all local.
i just said that srv is now a 9p-service-only tree.
everything posted there *must* serve 9p.
if you post an fd and someone else opens it,
the kernel brokers the 9p messages going across
it so that other people who open it see an independent
conversation while the guy who posted sees a single
conversation in which everything is multiplexed properly.
this requires no extra processes -- a write to a server
side fd goes through to the server and a write to the
client side fd goes through to the client. it requires
routing during the read/write, but nothing else.
> it could know by looking at the device letter, or by a mode bit in the
> file. let's assume the latter, as it's more general (and reducible to
> the former).
the kernel knows whether a file is in /srv because the kernel
serves that tree. it has to, so that the correct read/write/open/close
etc. routines get called.
> say we've imported a namespace from a remote machine. in the
> namespace is a /srv directory, containing various exported 9p
> services. we wish to mount one of them.
let's hold off on that. i said i didn't know how to deal
with networks properly. thinking about this a little more,
i think i see what you were getting at in your message.
i think what i described and what you described are
almost completely orthogonal. i'll expand on your stuff
in a separate message.
> > I don't see how to do authentication in user space and keep the
> > "reductions" of things like fd = exportfs("/a"); mount(fd, "/b", MREPL);.
>
> i'm not sure one needs to try.
>
> i think you're maybe glossing over something here too.
> one doesn't usually do the above, but actually:
>
> exportfs(p[0], "/a"); mount(p[1], "/b", MREPL);
>
> where p[0] and p[1] are two ends of a pipe.
> presumably the kernel would have to know about the pipe
> device as a special case?
only if you think exportfs should be told where to write
if the system call is really fd = exportfs("/a"), there is no pipe.
that's also why there are no extra processes. in order to
implement /bin/exportfs you'd have to get the export fd
and then ferry bytes between stdin/stdout and the fd.
if you really care you could put a generic trampoline(fd1, fd2)
into the kernel.
> > Suppose the kernel were a good 9P multiplexor instead
> > of a cleaner Unix kernel with devmnt hanging on the side.
>
> i think what i like least about this scheme is that you need lots of
> extra processes... all of which are unnecessary.
there are no extra processes. all of which are bright purple,
or anything else you like. there aren't any.
> one thing that's really nice about the current kernel scheme is that a
> file operation at user level is just a function call in the kernel.
> you already have the process context around, and that's what gets used.
this can still be the case.
> if devices speak in terms of 9p messages, you're talking about a
> stream of 9p messages. many processes write messages into the stream,
> and then you need many processes at the other side to deal with the
> concurrency (as exportfs does). you're dealing with a many-one-many
> mapping, rather than the current simple one-one scheme, not to mention
> the additional data copying, context switches and fid/tag counting.
you're ignoring things i said. inside the kernel there is only some
data structure representation like Fcall or lib9p's Req. no need for
copying as the messages move around inside (unless you're worrying
about the cost of copying pointers). there might be context switches
depending on how you implement things, but they would all be between
kernel processes so they'd be cheap. fid/tag manipulation is free.
the "other side" can have as many processes as it needs to handle
the concurrency. the handler for a read from /dev/user could handle
the request immediately. the handler for a read from /dev/cons might
put it on a queue of pending reads. in general there's no need for
one-process-per-writer unless you're assuming the devices slip back
into function calls at some point instead of dealing with the 9p
requests directly.
again, remember that this is all local. i'm not claiming to solve
any problems with doing 9p over 9p or over a network.
> > What I don't really understand about your scheme is how much
> > you're getting from an auth file being authentication-related and
> > how much you're getting from it being the beginning of a 9P
> > connection.
>
> it's crucial that you can do the authentication, as it allows a
> service to multiplex several different users onto the same connection.
> as charles likes to point out, the "important" authentication is the
> kind that Styx uses - i.e. end to end. however, once you've
> connected to a party you trust (to some extent) to act on your behalf,
> it's still useful to be able to authenticate yourself to third parties
> through them.
>
> to some services the identity of the user doesn't matter. others rely
> on it totally (for instance /proc).
>
> i'm not sure exactly what form local authentication should take though.
i agree with all this.
> [you can defer the decision though: suppose that all kernel
> level devices believed whatever user was named in the attach message.
> then imagine a device which, given an auth fd, produced another
> auth fd that required the client to satisfy certain authentication criteria
> - once satisfied, an attach would attach to the original device,
> as the correct (and authenticated) user. in this way you could push
> whatever authentication scheme you liked onto all the kernel devices
> available in /srv]
neat.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [9fans] remote 9p multiplexing
2004-04-26 18:09 ` rog
2004-04-26 18:44 ` [9fans] local 9p multiplexing Russ Cox
@ 2004-04-26 18:54 ` Russ Cox
2004-04-26 19:44 ` rog
2004-04-28 17:37 ` [9fans] Vmware-4 and Plan 9 Ishwar Rattan
2004-04-26 18:55 ` [9fans] an idea Charles Forsyth
2004-04-26 19:51 ` ron minnich
3 siblings, 2 replies; 67+ messages in thread
From: Russ Cox @ 2004-04-26 18:54 UTC (permalink / raw)
To: 9fans
> say we've imported a namespace from a remote machine. in the
> namespace is a /srv directory, containing various exported 9p
> services. we wish to mount one of them.
okay, let's return to this. in my scheme, since the remote kernel
is doing appropriate multiplexing, we don't need to do anything
special to use the remote /srv/foo. (actually, we the local machine
don't need to do anything special even now, but that's because
exportfs the program is invoking itself recursively behind our back.)
of course, since /srv/foo is treated like a normal file, there is
message encapsulation and the like, which does incur extra
latency. i never claimed to handle this case. i didn't realize
you were claiming to handle it.
it seems what's needed to handle it is some way to introduce a
new conversation into an extant 9P connection. david mazieres
suggested such a thing a few years ago when he interned at
bell labs. in his scheme there was (approximately) a Ttunnel/Rtunnel
message that took the place of Topen/Ropen for 9P connections,
and the net effect was that the 9P connection just opened could
use the original 9P connection for its messages rather than
encapsulate them in Tread/Rread/Twrite/Rwrite responses.
i never understood the details (i'm not sure anyone did).
i think the crux of your message is that Tauth/Rauth can be coerced
to let us pull this off, because it introduces a separate "attach space".
i'm going to try to paraphrase:
when afd != -1, the fd in mount(fd, afd, where, flags) is redundant.
if you mounted 9P services by opening them, running authentication,
and then calling mount(afd, where, flags), we could adopt the convention
that the 9P connection for the mount is the one where afd is a fid.
then Tauth invents a fid out of thin air to bootstrap a connection,
but if the fid has been gotten by open, mounting this fid can be
handled without further encapsulation.
now *that* is cool. the auth fids are really an indirection layer
and Tauth/Rauth just provides a base. of course, they'd more
properly be called something else, since this has nothing to
do with authentication and everything to do with setting up the
context of a new 9P conversation. maybe session fids.
that's really neat. it separates the setup from the actual session
in a nice clean way without the clumsy 9P1 kernel hack and
without any encapsulation overhead.
sorry about being so dense i didn't get it the first time around.
russ
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 18:09 ` rog
2004-04-26 18:44 ` [9fans] local 9p multiplexing Russ Cox
2004-04-26 18:54 ` [9fans] remote " Russ Cox
@ 2004-04-26 18:55 ` Charles Forsyth
2004-04-26 20:12 ` rog
2004-04-26 19:51 ` ron minnich
3 siblings, 1 reply; 67+ messages in thread
From: Charles Forsyth @ 2004-04-26 18:55 UTC (permalink / raw)
To: 9fans
>>it's crucial that you can do the authentication, as it allows a
>>service to multiplex several different users onto the same connection.
>>as charles likes to point out, the "important" authentication is the
>>kind that Styx uses - i.e. end to end. however, once you've
>>connected to a party you trust (to some extent) to act on your behalf,
>>it's still useful to be able to authenticate yourself to third parties
>>through them.
i say that because the end to end one is the only one that gives you reliable data.
there's not much point doing the others, from the third party server's point of view.
if you authenticate to a server, and use that to connect to another server,
that server must trust the first server to speak for every user it sees on
the connection, and it must know that.
that's because the multiplexing system is in a position to manipulate fids on the connection,
including the attach fids carefully associated with an `authenticated' user by an afid.
having made the association, how does it really know who uses which?
I am he as you are he as you are me and we are all together.
it doesn't even require a modified kernel, just control of the messages on the connection.
thus the multiplexing might as well be just as in Styx: different user names
[whatever that might mean in a larger context] label the Tattach messages on the connection.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] remote 9p multiplexing
2004-04-26 18:54 ` [9fans] remote " Russ Cox
@ 2004-04-26 19:44 ` rog
2004-04-28 17:37 ` [9fans] Vmware-4 and Plan 9 Ishwar Rattan
1 sibling, 0 replies; 67+ messages in thread
From: rog @ 2004-04-26 19:44 UTC (permalink / raw)
To: 9fans
> when afd != -1, the fd in mount(fd, afd, where, flags) is redundant.
> if you mounted 9P services by opening them, running authentication,
> and then calling mount(afd, where, flags), we could adopt the convention
> that the 9P connection for the mount is the one where afd is a fid.
yes.
> then Tauth invents a fid out of thin air to bootstrap a connection,
> but if the fid has been gotten by open, mounting this fid can be
> handled without further encapsulation.
actually, i was imagining that you would not be allowed
to open an auth file, only Tauth it. the open doesn't really
give you much and you've got to call auth to provide
the uname and aname before you can read or write it anyway.
this does change current 9p semantics (currently the auth fid
must not currently exist; in this scheme it could optionally exist),
but in a compatible way.
> of course, they'd more properly be called something else, since this
> has nothing to do with authentication and everything to do with
> setting up the context of a new 9P conversation. maybe session fids.
i'm not sure - i think auth fids is *exactly* what they are. by
walking to it and calling fauth(2) on it, you're introducing yourself
(authenticating) to whatever's at the other end.
the 'A' that you might see in an ls -l listing could also stand for "attach"...
but they'd be potentially useful even without doing the attach, as a way
for a client to ascertain the identity of a party at the other end.
> that's really neat. it separates the setup from the actual session
> in a nice clean way without the clumsy 9P1 kernel hack and
> without any encapsulation overhead.
there's more to it than that.
it makes possible some useful 9p server designs that were not
previously possible.
for instance, it becomes much more reasonable to implement a web
browser in the namespace. the server could provide a namespace for a
single web page, holding the data for the page, but also an auth file
for each link in the page. mounting the auth file would provide the
namespace for the page linked to. (https authentication falls out
naturally). deciding which web pages to keep current (i.e. mounted)
is a matter for the client, as it should be.
it also makes sense for servers that wish to provide multiple
instances of a service, but don't care about letting clients see all
the instances that have been created, in the same way that the #|
device does.
to take a specific example, the Inferno grid scheduler program exports
a single namespace to all its clients. one of those files, when
opened, represents a single worker instance to the server. if i'm on
a multi-process machine, i can open the file several times, and the
server sees several workers. the difficulty comes when i wish to send
an abort message to a particular worker - the same worker might have
opened the "stoptask" file, but i have no way of associating the two
opens, so i am forced to provide one such file for each attach, and
let the client do the multiplexing.
the current alternative would be to provide a "clone"-style interface,
with one directory for each worker, each containing two files. not
only does that make the server implementation more complex (have to be
able to enumerate all clients, have to allocate appropriate qid space,
etc) but it also makes the client interface more complex
(open clone file, read id, etc, vs. open file).
the auth file interface gives me the best of both worlds: i could
provide an auth file for workers to attach to, giving each a namespace
containing the two files (and any others necessary), and wouldn't have
to worry about enumerability or qid space at all.
oh yes, it also seems a natural representation for dynamically loaded
device drivers.
and it can solve world hunger too.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 18:09 ` rog
` (2 preceding siblings ...)
2004-04-26 18:55 ` [9fans] an idea Charles Forsyth
@ 2004-04-26 19:51 ` ron minnich
2004-04-26 20:49 ` Charles Forsyth
3 siblings, 1 reply; 67+ messages in thread
From: ron minnich @ 2004-04-26 19:51 UTC (permalink / raw)
To: 9fans
On Mon, 26 Apr 2004 rog@vitanuova.com wrote:
> if devices speak in terms of 9p messages, you're talking about a
> stream of 9p messages.
This part is a tiny bit worrisome for me but I didn't want to bring it up.
Messages to kernel bits reminds me of Mach somehow. What happened to Mach
was sometimes referred to as "message death".
ron
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 18:55 ` [9fans] an idea Charles Forsyth
@ 2004-04-26 20:12 ` rog
2004-04-26 20:40 ` Charles Forsyth
0 siblings, 1 reply; 67+ messages in thread
From: rog @ 2004-04-26 20:12 UTC (permalink / raw)
To: 9fans
> from the third party server's point of view.
> if you authenticate to a server, and use that to connect to another server,
> that server must trust the first server to speak for every user it sees on
> the connection, and it must know that.
i think this is a reasonably common scenario.
> thus the multiplexing might as well be just as in Styx: different user
> names [whatever that might mean in a larger context] label the Tattach
> messages on the connection.
that assumes, i think, that authentication is homogeneous throughout
that system (i.e. that one agent can authenticate all users uniformly
at the outer edge of the system). i'm not sure that's realistic.
in the simplest case, the first server is the kernel, and i find it
reasonable to trust it to speak for every user i authenticate as. if
i trust the kernel, why shouldn't i trust other services i have
started up, in the same way? there are occasions when i might extend
the same level of trust to other machines too.
from the server's point of view, it should not trust in-band
authentications along a channel that has not been end-to-end
authenticated in a way that it trusts.
that's a matter for whoever is arranging the topology of the system,
surely?
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 18:36 ` Philippe Anel
@ 2004-04-26 20:27 ` rog
2004-04-27 7:44 ` Philippe Anel
2004-04-27 8:13 ` Fco.J.Ballesteros
1 sibling, 1 reply; 67+ messages in thread
From: rog @ 2004-04-26 20:27 UTC (permalink / raw)
To: 9fans
> I think capabilities would help here.
the namespace is a capability.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 20:12 ` rog
@ 2004-04-26 20:40 ` Charles Forsyth
2004-04-26 23:26 ` rog
0 siblings, 1 reply; 67+ messages in thread
From: Charles Forsyth @ 2004-04-26 20:40 UTC (permalink / raw)
To: 9fans
>>that's a matter for whoever is arranging the topology of the system,
>>surely?
no, i don't think it is. i think what happens is that Tauth/Rauth seems
cute and people keep trying to find a reason to keep it, but it's useful
for only the reason it was introduced: to take the authentication out
of the protocol proper for those file servers (/sys/src/fs) that don't do
authentication otherwise.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 19:51 ` ron minnich
@ 2004-04-26 20:49 ` Charles Forsyth
0 siblings, 0 replies; 67+ messages in thread
From: Charles Forsyth @ 2004-04-26 20:49 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
>>Messages to kernel bits reminds me of Mach somehow. What happened to Mach
>>was sometimes referred to as "message death".
that was bad. i might have chosen the 4.2bsd design document.
not messaging but a similar feel of much mechanism more complex
than that it replaces (which is all that anyone ends up using anyway
for some reason).
nevertheless, there have been good message passing systems;
it's just that (perhaps) Mach wasn't one of them. i admit it was never one of my favourites.
still, to focus on the export aspect is possibly sensible
since that apparently has been surprisingly troublesome all round.
even there, part of the problem i think has been the usual one
of gradually working out what the specification actually was, incrementally.
eventually, one reaches a stage where it all seems quite obvious,
but by that time, so many people have jaundiced opinions about it.
[-- Attachment #2: Type: message/rfc822, Size: 2611 bytes --]
From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] an idea
Date: Mon, 26 Apr 2004 13:51:33 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0404261350180.28350-100000@maxroach.lanl.gov>
On Mon, 26 Apr 2004 rog@vitanuova.com wrote:
> if devices speak in terms of 9p messages, you're talking about a
> stream of 9p messages.
This part is a tiny bit worrisome for me but I didn't want to bring it up.
Messages to kernel bits reminds me of Mach somehow. What happened to Mach
was sometimes referred to as "message death".
ron
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 20:40 ` Charles Forsyth
@ 2004-04-26 23:26 ` rog
0 siblings, 0 replies; 67+ messages in thread
From: rog @ 2004-04-26 23:26 UTC (permalink / raw)
To: 9fans
> [Tauth/Rauth is] useful for only the reason it was introduced: to take
> the authentication out of the protocol proper for those file servers
> (/sys/src/fs) that don't do authentication otherwise.
i think that's a bit strong.
if i am connecting to a service through a mutually trusted third party
(a CPU server, for example) then might this kind of authentication not
be useful?
from the service's point of view, only the third party has the
capability to mix up users. from my point of view, only the third
party can act illegitimately on my behalf. since we both trust the
third party, surely there's no problem?
as an example, consider the inferno demo grid (*). it's providing a
range of services through a single Styx connection. with the current
scheme, all services have to be part of the same user domain. however
the "spree" games service allows a different set of users. using
Tauth/Rauth, that service could authenticate a remote user
appropriately through the same connection, rather than needing to
listen on a separate tcp port as currently.
i'm probably missing something, but that sounds reasonable
(and useful) to me.
* http://www.vitanuova.com/solutions/grid/demogrid.html, for those
interested.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 7:57 ` Fco.J.Ballesteros
2004-04-26 8:04 ` Charles Forsyth
2004-04-26 16:41 ` rog
@ 2004-04-27 1:44 ` Scott Schwartz
2004-04-27 6:43 ` Fco.J.Ballesteros
2 siblings, 1 reply; 67+ messages in thread
From: Scott Schwartz @ 2004-04-27 1:44 UTC (permalink / raw)
To: 9fans
On Mon, Apr 26, 2004 at 09:57:05AM +0200, Fco. J. Ballesteros wrote:
> But this could be done by arranging the the final clients to talk to the
> actual servers, without resorting to proxy places. But this would require
> changing the name space semantics. We do that for Plan B, but don't know
> how it would fit with Plan 9. To make it more clear what I mean,
> one way to do it would be to make all 9P servers become network addressable,
> then change the way the ns is printed so that a user could reproduce the
> ns from any other place in the network.
Without understanding all the details, it seems like that breaks a
feature of Plan 9, namely that namespaces work somewhat like lexical
scoping, where some things just plain aren't visible from the outside.
It seems like exporting a local name could be thought of somewhat like
a functional closure, where you'd have some opaque cookie to be shared
with friends that referred directly to the things in your scope, but that
you couldn't generate from outside the namespace. If I recall correctly,
Amoeba did something like that. Also, Prospero had some idea of closure,
but I can't remember how that actually worked.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-27 1:44 ` Scott Schwartz
@ 2004-04-27 6:43 ` Fco.J.Ballesteros
0 siblings, 0 replies; 67+ messages in thread
From: Fco.J.Ballesteros @ 2004-04-27 6:43 UTC (permalink / raw)
To: 9fans
> Without understanding all the details, it seems like that breaks a
> feature of Plan 9, namely that namespaces work somewhat like lexical
> scoping, where some things just plain aren't visible from the outside.
> It seems like exporting a local name could be thought of somewhat like
> a functional closure
That's interesting. I think that it would be like you say only if
the mechanism is missused. The net effect of doing what I say
would be like evaluating the NS until the point when the entries
resolve right to the providers. Not what amoeba did.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 20:27 ` rog
@ 2004-04-27 7:44 ` Philippe Anel
0 siblings, 0 replies; 67+ messages in thread
From: Philippe Anel @ 2004-04-27 7:44 UTC (permalink / raw)
To: 9fans
At 22:27 26/04/04, you wrote:
> > I think capabilities would help here.
>
>the namespace is a capability.
Yes. But devices are not in that namespace.
Every process has access to #, hence the
need to have RFNOMNT and exceptions in namec().
Without #, there is no need to have both
exceptions in namec and RFNOMNT.
Regards,
Philippe.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] an idea
2004-04-26 18:36 ` Philippe Anel
2004-04-26 20:27 ` rog
@ 2004-04-27 8:13 ` Fco.J.Ballesteros
1 sibling, 0 replies; 67+ messages in thread
From: Fco.J.Ballesteros @ 2004-04-27 8:13 UTC (permalink / raw)
To: 9fans
> In fact I'd like to build a kind of a microkernel without the task/thread
> stuff, but entierly based on channels (ports) capabilities and 9p2000.
Get VSTa, it does mostly that (not 9p though).
^ permalink raw reply [flat|nested] 67+ messages in thread
* [9fans] Vmware-4 and Plan 9..
2004-04-26 18:54 ` [9fans] remote " Russ Cox
2004-04-26 19:44 ` rog
@ 2004-04-28 17:37 ` Ishwar Rattan
2004-04-28 17:58 ` Hugo Santos
2004-04-28 18:01 ` vic zandy
1 sibling, 2 replies; 67+ messages in thread
From: Ishwar Rattan @ 2004-04-28 17:37 UTC (permalink / raw)
To: 9fans
I am seeing a strange problem. I am trying to boot plan9-cd to boot
under vmware-4.0, this is where it stops..
MBR...PBS...Plan 9 from Bell Labs
ECLR: 0E00
apm ax=0f000 cx=f000 dx=40 di=ffff ebx=5a43 esi=-1
dev A0 port 1F0 config 427A capabilities 2F00 mwdma 0007 udma 0207
dev A0 port 170 config 85C4 capabilities 0F00 mwdma 0007 udma 0207
--> hangs
I downloaded the vmware.zip fiel too and I see similar behavior except
for ECLR value is 0200
Any pointers?
-ishwar
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] Vmware-4 and Plan 9..
2004-04-28 17:37 ` [9fans] Vmware-4 and Plan 9 Ishwar Rattan
@ 2004-04-28 17:58 ` Hugo Santos
2004-04-28 18:01 ` vic zandy
1 sibling, 0 replies; 67+ messages in thread
From: Hugo Santos @ 2004-04-28 17:58 UTC (permalink / raw)
To: 9fans
Set VMWare's CD parameter 'legacy mode'. You'll find that option in the
VM config.
Hugo
On Wed, 2004-04-28 at 13:37 -0400, Ishwar Rattan wrote:
> I am seeing a strange problem. I am trying to boot plan9-cd to boot
> under vmware-4.0, this is where it stops..
>
> MBR...PBS...Plan 9 from Bell Labs
> ECLR: 0E00
> apm ax=0f000 cx=f000 dx=40 di=ffff ebx=5a43 esi=-1
> dev A0 port 1F0 config 427A capabilities 2F00 mwdma 0007 udma 0207
> dev A0 port 170 config 85C4 capabilities 0F00 mwdma 0007 udma 0207
> --> hangs
>
> I downloaded the vmware.zip fiel too and I see similar behavior except
> for ECLR value is 0200
>
> Any pointers?
>
> -ishwar
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [9fans] Vmware-4 and Plan 9..
2004-04-28 17:37 ` [9fans] Vmware-4 and Plan 9 Ishwar Rattan
2004-04-28 17:58 ` Hugo Santos
@ 2004-04-28 18:01 ` vic zandy
1 sibling, 0 replies; 67+ messages in thread
From: vic zandy @ 2004-04-28 18:01 UTC (permalink / raw)
To: 9fans
> MBR...PBS...Plan 9 from Bell Labs
> ECLR: 0E00
> apm ax=0f000 cx=f000 dx=40 di=ffff ebx=5a43 esi=-1
> dev A0 port 1F0 config 427A capabilities 2F00 mwdma 0007 udma 0207
> dev A0 port 170 config 85C4 capabilities 0F00 mwdma 0007 udma 0207
> --> hangs
I saw this hang in all my vmware plan 9 virtual
machines after I upgraded to vmware 4.5. Somehow the
behavior persisted even after I reverted back to vmware
4.0.5. (I was able to boot the plan 9 install floppy
image in 4.5.)
After I removed from the virtual machines all devices
except disk, NIC, and memory I could boot them in 4.0.5
again.
^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2004-04-28 18:01 UTC | newest]
Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-11 19:14 [9fans] german keymap Scusi
2004-04-11 19:28 ` boyd, rounin
2004-04-11 20:00 ` Scusi
2004-04-11 20:03 ` boyd, rounin
2004-04-11 22:10 ` Geoff Collyer
2004-04-11 22:39 ` Russ Cox
2004-04-11 22:55 ` Geoff Collyer
2004-04-12 0:01 ` Russ Cox
2004-04-12 0:06 ` Geoff Collyer
2004-04-12 0:22 ` Charles Forsyth
2004-04-12 2:42 ` boyd, rounin
2004-04-12 2:57 ` countryjoe
2004-04-12 4:02 ` boyd, rounin
2004-04-12 2:40 ` boyd, rounin
2004-04-12 2:35 ` boyd, rounin
2004-04-12 2:33 ` boyd, rounin
2004-04-21 17:43 ` rog
2004-04-21 17:44 ` boyd, rounin
2004-04-21 17:56 ` rog
2004-04-21 18:03 ` boyd, rounin
2004-04-21 18:41 ` rog
2004-04-21 18:42 ` Rob Pike
2004-04-21 19:16 ` rog
2004-04-21 18:43 ` boyd, rounin
2004-04-21 18:47 ` boyd, rounin
2004-04-21 18:57 ` Rob Pike
2004-04-21 18:58 ` boyd, rounin
2004-04-21 19:20 ` rog
2004-04-21 19:58 ` boyd, rounin
2004-04-21 20:26 ` rog
2004-04-21 21:26 ` [9fans] an idea rog
2004-04-26 7:57 ` Fco.J.Ballesteros
2004-04-26 8:04 ` Charles Forsyth
2004-04-26 8:10 ` Fco.J.Ballesteros
2004-04-26 8:13 ` Charles Forsyth
2004-04-26 16:41 ` rog
2004-04-26 16:43 ` Charles Forsyth
2004-04-26 16:57 ` rog
2004-04-26 16:48 ` Fco.J.Ballesteros
2004-04-27 1:44 ` Scott Schwartz
2004-04-27 6:43 ` Fco.J.Ballesteros
2004-04-26 15:12 ` Russ Cox
2004-04-26 15:49 ` ron minnich
2004-04-26 16:42 ` rog
2004-04-26 16:59 ` Russ Cox
2004-04-26 17:05 ` Charles Forsyth
2004-04-26 18:04 ` Philippe Anel
2004-04-26 18:16 ` rog
2004-04-26 18:36 ` Philippe Anel
2004-04-26 20:27 ` rog
2004-04-27 7:44 ` Philippe Anel
2004-04-27 8:13 ` Fco.J.Ballesteros
2004-04-26 18:20 ` rog
2004-04-26 18:09 ` rog
2004-04-26 18:44 ` [9fans] local 9p multiplexing Russ Cox
2004-04-26 18:54 ` [9fans] remote " Russ Cox
2004-04-26 19:44 ` rog
2004-04-28 17:37 ` [9fans] Vmware-4 and Plan 9 Ishwar Rattan
2004-04-28 17:58 ` Hugo Santos
2004-04-28 18:01 ` vic zandy
2004-04-26 18:55 ` [9fans] an idea Charles Forsyth
2004-04-26 20:12 ` rog
2004-04-26 20:40 ` Charles Forsyth
2004-04-26 23:26 ` rog
2004-04-26 19:51 ` ron minnich
2004-04-26 20:49 ` Charles Forsyth
2004-04-22 1:57 ` [9fans] german keymap Michael Jeffrey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).