Re: [9fans] a few misc. questions...
ah, the latest n00b writing tutorials :) welcome to the club there is also this... http://www.magma.com.ni/moin/Plan9Tutorial So, I'm beginning with a tutorial
Re: [9fans] a few misc. questions...
there is also this... http://www.magma.com.ni/moin/Plan9Tutorial On Thu, Jul 23, 2009 at 12:36 AM, Corey wrote: > > Thanks for the comments everyone. > > > Once I got to a point where I had a cpu/auth server kindof working, and had > become slightly more comfortable with the bare rudimentary basics of > working in rio & acme, I decided to stop, and start all over again from > scratch - but this time taking extensive notes on each particular little > step, and integrating the advice and knowledge I've been gleaning > from my questions to 9fans. > > I'm doing this because I'd like to turn my notes into a fairly complete Plan 9 > tutorial, aimed toward interested and motivated users who have no existing > prior Plan 9 experience. > > I know that there's plenty of good documentation on the web and on > the system via the man pages, but I'd like to put together something > more cohesive and organized and which progresses from simple topics > to more advanced topics in fairly logical manner. > > So, I'm beginning with a tutorial that details the focused task of _simply_ > getting a mere standalone terminal installed and configured, either onto a > machine or using qemu. Having followed this first chapter (installation), the > newly operable terminal will then be used by the tutorial as the platform from > which to introduce the reader/user to the initial primary topics any Plan 9 > user ought to be familiar with: > > intro to basic security > intro to rio > intro to man > intro to acme > intro to rc and basic commands, and directory structure > intro to /usr//[bin,lib] files, and how/when to use > intro to namespaces > intro to pull > intro to sources > intro to the boot sequence and what gets executed when and how > intro to filesystems: kfs and/or fossil > intro to patch > intro to 9fans, etiquette and Plan 9 idioms > > These are placed in the order to which each topic will be introduced, and > each intro will purposefully be rather short, say, 1-3 pages - mere basic, > introductory level amount of detail; each chapter will end with references > to further information relevant to the topic. > > > From there, I can add other tutorials, where each tutorial progresses a > step or so toward more advanced uses - and each beginning with an > installation and configuration chapter, which then leads into various > other chapters detailing specific topics closely related to the tutorial's > major topic. > > 1: standalone terminal installation & configuration tutorial > > 2: cpu server intallation & configuration tutorial > > 3: authentication server configuration tutorial > (takes the above cputerm and adds auth) > > 4: terminal connected to cpu/auth server configuration > (takes the standalone terminal, and explains how to connect to > the user's new cpu/auth server from tutorial #3) > > 5: fileserver installation and configuration > > 6: terminal connected to fileserver configuration > > > ... so a total of, maybe 6 tutorials, that combined, pretty much hit the > common use cases - organized in a logical progressive order that a reader > can follow through from start to finish and have a pretty decent handle of a > typical Plan 9 environment upon completing. > > > Anyhow, just wanted to get that out there; I'll just have to see whether > I keep the momentum - hopefully I will. Once I have something more > concrete I'll be sure to host it somewhere, preferably via a medium that > allows community edits/comments, etc. > > ( this is assuming nothing similar already exists - I was unable to really > find anything along the same lines; closest was this newbie-guide: > http://www.covingtoninnovations.com/michael/blog/0807/newbie-guide.pdf ) > > > Cheers > > > On Tuesday 21 July 2009 22:21:16 Corey wrote: >> In no particular order. Your help is very much appreciated - still getting >> my legs on w/ plan 9; I make a real effort not to query the list until I'm >> at a standstill. >> > > > -- Federico G. Benavento
Re: [9fans] a few misc. questions...
Thanks for the comments everyone. Once I got to a point where I had a cpu/auth server kindof working, and had become slightly more comfortable with the bare rudimentary basics of working in rio & acme, I decided to stop, and start all over again from scratch - but this time taking extensive notes on each particular little step, and integrating the advice and knowledge I've been gleaning from my questions to 9fans. I'm doing this because I'd like to turn my notes into a fairly complete Plan 9 tutorial, aimed toward interested and motivated users who have no existing prior Plan 9 experience. I know that there's plenty of good documentation on the web and on the system via the man pages, but I'd like to put together something more cohesive and organized and which progresses from simple topics to more advanced topics in fairly logical manner. So, I'm beginning with a tutorial that details the focused task of _simply_ getting a mere standalone terminal installed and configured, either onto a machine or using qemu. Having followed this first chapter (installation), the newly operable terminal will then be used by the tutorial as the platform from which to introduce the reader/user to the initial primary topics any Plan 9 user ought to be familiar with: intro to basic security intro to rio intro to man intro to acme intro to rc and basic commands, and directory structure intro to /usr//[bin,lib] files, and how/when to use intro to namespaces intro to pull intro to sources intro to the boot sequence and what gets executed when and how intro to filesystems: kfs and/or fossil intro to patch intro to 9fans, etiquette and Plan 9 idioms These are placed in the order to which each topic will be introduced, and each intro will purposefully be rather short, say, 1-3 pages - mere basic, introductory level amount of detail; each chapter will end with references to further information relevant to the topic. From there, I can add other tutorials, where each tutorial progresses a step or so toward more advanced uses - and each beginning with an installation and configuration chapter, which then leads into various other chapters detailing specific topics closely related to the tutorial's major topic. 1: standalone terminal installation & configuration tutorial 2: cpu server intallation & configuration tutorial 3: authentication server configuration tutorial (takes the above cputerm and adds auth) 4: terminal connected to cpu/auth server configuration (takes the standalone terminal, and explains how to connect to the user's new cpu/auth server from tutorial #3) 5: fileserver installation and configuration 6: terminal connected to fileserver configuration ... so a total of, maybe 6 tutorials, that combined, pretty much hit the common use cases - organized in a logical progressive order that a reader can follow through from start to finish and have a pretty decent handle of a typical Plan 9 environment upon completing. Anyhow, just wanted to get that out there; I'll just have to see whether I keep the momentum - hopefully I will. Once I have something more concrete I'll be sure to host it somewhere, preferably via a medium that allows community edits/comments, etc. ( this is assuming nothing similar already exists - I was unable to really find anything along the same lines; closest was this newbie-guide: http://www.covingtoninnovations.com/michael/blog/0807/newbie-guide.pdf ) Cheers On Tuesday 21 July 2009 22:21:16 Corey wrote: > In no particular order. Your help is very much appreciated - still getting > my legs on w/ plan 9; I make a real effort not to query the list until I'm > at a standstill. >
Re: [9fans] a few misc. questions...
On Wed, Jul 22, 2009 at 10:57 AM, hiro <23h...@googlemail.com> wrote: > > Yeah, I'm pretty sure that, in an emulated environment, I'd pick kfs over > > Venti, most of the time, unless your goal is to learn about Venti and > Fossil > > Why specifically in an emulated environment? > Just because it seems easier to back stuff up from an image file on another OS if you're in emulation. Data can be backed up elsewhere. I suppose you could tar your KFS to anywhere though on a live system. Anyway, it was just my preference.
Re: [9fans] a few misc. questions...
> Yeah, I'm pretty sure that, in an emulated environment, I'd pick kfs over > Venti, most of the time, unless your goal is to learn about Venti and Fossil Why specifically in an emulated environment?
Re: [9fans] a few misc. questions...
On Wed, Jul 22, 2009 at 6:13 AM, erik quanstrom wrote: > > ... but which would be considered the most logical place to deal with > > things such as setting hd parameters for the machine on bootup like > > the 'echo dma on > /dev/sdC0/ctl' example above? > > also see dmaon(8). just as an obvious note, this only > affects interfaces using ide or ide emulation. you can > tell which driver you're using by catting /dev/sdctl. for > example, the first drive is ide. unfortunately, the driver > calls itself "ata". > > ladd# cat /dev/sdctl > sdC ata port 1F0 ctl 3F4 irq 14 > sdE ahci sb600 port 0xe0022800: 64a alp clo coal led mps ncq ntf pm pslum > slum iss 2 ncs 31 np 4 ghc 8002 isr 0 pi f 0-3 ver 10100 > > > > Kfs is the older disk file system for standalone terminals and the > like. > > > For most purposes, fossil replaces it. Fossil is user-mode, while kfs > > > is a "kernel file system." See in kfs(4). > > > > > > > Ok, so I may simply generally disregard any mention of kfs in any docs or > > scripts and config files I might happen upon? Since fossil has > effectively > > deprecated kfs? > > both (as noted) are user-level fses. and while kfs is older and > simpler, it is very robust. there may be more kfs in operation > than any other plan 9 fs. fossil does snapshots, talks to venti > and other things, but being more complicated, there are more > ways for it to go sideways. > > so like anything else you don't use, feel free to ignore. but > that doesn't mean kfs is "deprecated". i think it's just a different > tool for a different task. > Yeah, I'm pretty sure that, in an emulated environment, I'd pick kfs over Venti, most of the time, unless your goal is to learn about Venti and Fossil :-). You can do Fossil without Venti too, but it's not as fun :-) Dave > > - erik > >
Re: [9fans] a few misc. questions...
> ... but which would be considered the most logical place to deal with > things such as setting hd parameters for the machine on bootup like > the 'echo dma on > /dev/sdC0/ctl' example above? also see dmaon(8). just as an obvious note, this only affects interfaces using ide or ide emulation. you can tell which driver you're using by catting /dev/sdctl. for example, the first drive is ide. unfortunately, the driver calls itself "ata". ladd# cat /dev/sdctl sdC ata port 1F0 ctl 3F4 irq 14 sdE ahci sb600 port 0xe0022800: 64a alp clo coal led mps ncq ntf pm pslum slum iss 2 ncs 31 np 4 ghc 8002 isr 0 pi f 0-3 ver 10100 > > Kfs is the older disk file system for standalone terminals and the like. > > For most purposes, fossil replaces it. Fossil is user-mode, while kfs > > is a "kernel file system." See in kfs(4). > > > > Ok, so I may simply generally disregard any mention of kfs in any docs or > scripts and config files I might happen upon? Since fossil has effectively > deprecated kfs? both (as noted) are user-level fses. and while kfs is older and simpler, it is very robust. there may be more kfs in operation than any other plan 9 fs. fossil does snapshots, talks to venti and other things, but being more complicated, there are more ways for it to go sideways. so like anything else you don't use, feel free to ignore. but that doesn't mean kfs is "deprecated". i think it's just a different tool for a different task. - erik
Re: [9fans] a few misc. questions...
> /rc/bin/termrc > /rc/bin/termrc.local > /cfg/$sysname/termrc > ... but which would be considered the most logical place to deal with > things such as setting hd parameters for the machine on bootup like > the 'echo dma on > /dev/sdC0/ctl' example above? In /cfg/$sysname/termrc, because you might not want it for every machine you run. > What's the conventional wisdom regarding which of those scripts > are used for what purposes? i.e., when to prefer one over the Roughly speaking: /rc/bin/termrc - applies to all Plan 9 terminals everywhere /rc/bin/termrc.local - applies to all terminals on your network /cfg/$sysname/termrc - applies to one particular terminal > ( by the way, what to do when I find errors in the man pages? .e.g., in > the interest of correcting them upstream ) Submit a patch(1). > Ok, so I may simply generally disregard any mention of kfs in any docs or > scripts and config files I might happen upon? Yes, if you have only fossil installed.
Re: [9fans] a few misc. questions...
As a further question on that point, where would you say would be the best place to persist that command? As far as I'm aware, my likely choices would be one of (in order of execution): /rc/bin/termrc /rc/bin/termrc.local /cfg/$sysname/termrc I generally avoid touching termrc, put site-specific stuff for all machines on the network in termrc.local, and put machine-specific stuff in /cfg/$sysname/termrc (e.g. one machine supports dma but another does not.) "Cpurc" can be read for "termrc" above. ( by the way, what to do when I find errors in the man pages? .e.g., in the interest of correcting them upstream ) See patch(1). -Josh
Re: [9fans] a few misc. questions...
On Tuesday 21 July 2009 22:59:49 Josh Wood wrote: > > How do I enable hd dma? There's a dmamode=ask in my plan9.ini, but > > I don't > > see that option mentioned in the plan9.ini man. > > echo dma on > /dev/sdXY/ctl > > see in sd(3). > Excellent - thanks. As a further question on that point, where would you say would be the best place to persist that command? As far as I'm aware, my likely choices would be one of (in order of execution): /rc/bin/termrc /rc/bin/termrc.local /cfg/$sysname/termrc ... but which would be considered the most logical place to deal with things such as setting hd parameters for the machine on bootup like the 'echo dma on > /dev/sdC0/ctl' example above? I"m guessing it's best to execute hd params asap, so I'd put it in '/rc/bin/termrc' or '/rc/bin/termrc.local'. What's the conventional wisdom regarding which of those scripts are used for what purposes? i.e., when to prefer one over the others? ( cpurc(8) doesn't really provide any advice, other than describing the execution order ) ( I'm enjoying Plan 9's man pages - quality stuff ) ( by the way, what to do when I find errors in the man pages? .e.g., in the interest of correcting them upstream ) > Kfs is the older disk file system for standalone terminals and the like. > For most purposes, fossil replaces it. Fossil is user-mode, while kfs > is a "kernel file system." See in kfs(4). > Ok, so I may simply generally disregard any mention of kfs in any docs or scripts and config files I might happen upon? Since fossil has effectively deprecated kfs? > > "can't initialize venti /dev/scd0/arenas: arena header or trailer > > corrupted" > > My first guess is to ensure you haven't overlapped partitions or > something. > I just went ahead and reformated, and reran the install; solved the problem. I eventually noticed that the install script acts differently if it detects there's already a plan 9 partition layout on the disk. I had to completely delete then reformat the prior partition then restart the install. Thanks for the assistance!
Re: [9fans] a few misc. questions...
Fossil is user-mode, while kfs is a "kernel file system." This isn't the best way to say what I was trying to say, and may be misleading. Both are user programs; kfs is found at /$objtype/bin/disk/kfs. -Josh
Re: [9fans] a few misc. questions...
How do I enable hd dma? There's a dmamode=ask in my plan9.ini, but I don't see that option mentioned in the plan9.ini man. echo dma on > /dev/sdXY/ctl see in sd(3). I've been running into mention of kfs throughout various rc scripts and whatnot; is kfs simply the default file system for a plan 9 terminal? Kfs is the older disk file system for standalone terminals and the like. For most purposes, fossil replaces it. Fossil is user-mode, while kfs is a "kernel file system." See in kfs(4). Where's the boot log located (I looked in /sys/log)? I'm seeing some errors being printed to the console after I specified which user to log in as at the prompt, but those errors vanish too quickly for me to parse. cat /dev/kmesg You will usually need to be hostowner. See in cons(3). (And also kprint there, for routing the messages elsewhere.) Finally, regarding the errors I just mentioned, they seem to be something along the lines of: "can't initialize venti /dev/scd0/arenas: arena header or trailer corrupted" My first guess is to ensure you haven't overlapped partitions or something. -Josh
