* [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-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-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-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-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: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: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: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: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] 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-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 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: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 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 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-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 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 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 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: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
* 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: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
* 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 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
* [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] 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
* [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
* 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] 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 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 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 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 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] 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
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).