Re: [9fans] Brasil
Good question, it looks interesting, I also had intention to check inferno on parallela board On 2014-07-18 03:27 , Shane Morris wrote: Hello 9fans, I've been doing some research, and come across Brasil, which, if I've got this right, was a co-operating system minimal Inferno layer used on the Blue Gene/L project. Now, if I've got that wrong, please tell me...! This interests me, of course, as I prepare to bring up my Parallella board (I still need a fan for it - tsk tsk). Is there any source for Brasil available to the public, as my Google searches isn't showing any repos (but I did get this: http://graverobbers.blogspot.com.au/2009/05/few-words-on-brasil.html)? I understand the project to the Blue Gene/L was many years ago, and all of the IBM references on their website seem to have disappeared in the interim. Many thanks! Shane. signature.asc Description: OpenPGP digital signature
[9fans] Plan9 Sources Repository
Dear 9Fans, I see that Bell Labs offers a sources repository of Plan9, that is kindly kept up-to-date by volonteers (thanks!). Yet: is there a source control system behind it? Would it be possible to check out directly from there? If there is none, could it be that this contributes to the lack of popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy, PlanB, other plans...)? Kind Regards, Dante
[9fans] Keeping 9pi up to date
Dear Mr. Miller, Would a replica/pull -v /dist/replica/network result in the same system as the last 9pi kit (http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz)? Thanks, Dante
Re: [9fans] Plan9 Sources Repository
Sources is not kept up-to-date by volunteers, unless you mean contrib, it is maintained by the Labs. Also, in a way, the sources server *is* Plan 9, rather than being updated *with* Plan 9. Plan 9 doesn't traditionally use version control. Rather, most disk-based Plan 9 file servers offer some form of history in the form of dumps or snapshots. 9fs sourcesdump will mount the sources dump, and you can inspect daily changes starting around some 12 years ago using regular Plan 9 tools such as editors, yesterday(1) and diffy(1). History management is superior in Plan 9 compared to git and mercurial. What git does better (at least according to some people), is patch management. The Labs and 9atom use some patch management technology best described in their manuals rather than on the mailing list. 9front uses mercurial for patch management. -- Aram Hăvărneanu
Re: [9fans] Plan9 Sources Repository
Yet: is there a source control system behind it? Would it be possible to check out directly from there? for the bell-labs distribution, the filesystem itself keeps a daily record of the source tree. you can access it with 9fs sourcesdump and the daily state of sources will be in /n/sourcesdump. If there is none, could it be that this contributes to the lack of popularity 9front and 9legacy both use mercurial as their revision control systems. 9legacy keeps a mirror of the bell-labs distribution in mercurial as well if that suits your needs. 9front's repo: http://code.google.com/p/plan9front 9legacy's various repositories and mirrors: https://hg.9grid.fr/ and to the fragmentation of Plan9 (9front, 9atom, 9legacy, PlanB, other plans...)? the reason for the different distributions is really no different than the motivation for the different bsd or linux distributions: they each have their own goals and purpose.
Re: [9fans] Plan9 Sources Repository
Yet: is there a source control system behind it? Would it be possible to check out directly from there? there is nothing most folks would recognize as a distributed revision control system. the repo is sources itself. history is through history(1). you can check out code with cp(1), tar(1), mkfs(8); you can keep up with the repo with replica(1). patches are submitted via patch(1). If there is none, could it be that this contributes to the lack of popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy, PlanB, other plans...)? i would think the lack of popularity can be most directly attributed to the closed license in the early 90s, when there was an unfilled niche, and linux was seriously lacking. i starting doing something slightly different when il was pulled from the distribution while i was in no position to stop using it. it had nothing to do with source control. - erik
Re: [9fans] Keeping 9pi up to date
Would a replica/pull -v /dist/replica/network result in the same system as the last 9pi kit (http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz)? Almost. See http://9fans.net/archive/2014/02/131 for details.
Re: [9fans] file server speed
perhaps high-efficiency wall warts could make up much of the difference. picked at random (first link) ... http://www.amazon.com/Nokia-AC-10U-Micro-USB-Efficiency-Charger/dp/B00DP0TQLG Given that the rpi has some weird power issues and without specification of the amperage of the charger this might be bad advice.
Re: [9fans] Brasil
I thought it was the old name of plan9: http://swtch.com/plan9history/?p=1999/1031;v=difflist On Jul 17, 2014, at 6:27 PM, Shane Morris edgecombe...@gmail.commailto:edgecombe...@gmail.com wrote: Hello 9fans, I've been doing some research, and come across Brasil, which, if I've got this right, was a co-operating system minimal Inferno layer used on the Blue Gene/L project. Now, if I've got that wrong, please tell me...! This interests me, of course, as I prepare to bring up my Parallella board (I still need a fan for it - tsk tsk). Is there any source for Brasil available to the public, as my Google searches isn't showing any repos (but I did get this: http://graverobbers.blogspot.com.au/2009/05/few-words-on-brasil.htmlhttps://urldefense.proofpoint.com/v1/url?u=http://graverobbers.blogspot.com.au/2009/05/few-words-on-brasil.htmlk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=%2FN9d7W2LRwZks3eyFNLr8Q%3D%3D%0Am=l%2BBsm7%2BlVWmJmPdPZbten9gJKhTsnbvypiAsH%2BGxkL4%3D%0As=7c33e4970ebdb19f3165317703e92f3ffc884e81b92a17b9002edb096d99a467)? I understand the project to the Blue Gene/L was many years ago, and all of the IBM references on their website seem to have disappeared in the interim. Many thanks! Shane.
Re: [9fans] Brasil
It was re-used On 18 July 2014 18:30, Yoann Padioleau p...@fb.com wrote: I thought it was the old name of plan9: http://swtch.com/plan9history/?p=1999/1031;v=difflist On Jul 17, 2014, at 6:27 PM, Shane Morris edgecombe...@gmail.com wrote: Hello 9fans, I've been doing some research, and come across Brasil, which, if I've got this right, was a co-operating system minimal Inferno layer used on the Blue Gene/L project. Now, if I've got that wrong, please tell me...! This interests me, of course, as I prepare to bring up my Parallella board (I still need a fan for it - tsk tsk). Is there any source for Brasil available to the public, as my Google searches isn't showing any repos (but I did get this: http://graverobbers.blogspot.com.au/2009/05/few-words-on-brasil.html https://urldefense.proofpoint.com/v1/url?u=http://graverobbers.blogspot.com.au/2009/05/few-words-on-brasil.htmlk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=%2FN9d7W2LRwZks3eyFNLr8Q%3D%3D%0Am=l%2BBsm7%2BlVWmJmPdPZbten9gJKhTsnbvypiAsH%2BGxkL4%3D%0As=7c33e4970ebdb19f3165317703e92f3ffc884e81b92a17b9002edb096d99a467)? I understand the project to the Blue Gene/L was many years ago, and all of the IBM references on their website seem to have disappeared in the interim. Many thanks! Shane.
Re: [9fans] file server speed
On Fri Jul 18 12:51:49 EDT 2014, 23h...@gmail.com wrote: perhaps high-efficiency wall warts could make up much of the difference. picked at random (first link) ... http://www.amazon.com/Nokia-AC-10U-Micro-USB-Efficiency-Charger/dp/B00DP0TQLG Given that the rpi has some weird power issues and without specification of the amperage of the charger this might be bad advice. good point. thanks for pointing that out. - erik
Re: [9fans] file server speed
On Fri, 18 Jul 2014 15:36:09 EDT erik quanstrom quans...@quanstro.net wrote: On Fri Jul 18 12:51:49 EDT 2014, 23h...@gmail.com wrote: perhaps high-efficiency wall warts could make up much of the difference. picked at random (first link) ... http://www.amazon.com/Nokia-AC-10U-Micro-USB-Efficiency-Charger/dp/B00DP0 TQLG Given that the rpi has some weird power issues and without specification of the amperage of the charger this might be bad advice. good point. thanks for pointing that out. The new B+ has a switching regulator. It uses less power and it is more tolerant of voltage changes -- below 5V USB will stop working but there are reports of booting Linux to login screen on as low as 2.6V. So power issues should be resolved.
Re: [9fans] sam for Windows?
On 7/10/2014 9:43 AM, Russ Cox rsc-at-swtch.com |9fans| wrote: On Thu, Jul 3, 2014 at 1:39 AM, 6o205z...@sneakemail.com mailto:6o205z...@sneakemail.com wrote: On 6/27/2014 4:38 PM, Russ Cox rsc-at-swtch.com http://rsc-at-swtch.com |9fans| wrote: However, Steve Simon buried the lede in his reply: https://bitbucket.org/knieriem/pf9/downloads has a working sam, acme, plumber, etc in binary form. I just tested that sam and acme from there both work on my fussy 64-bit Windows machine. And they're in color! Thanks Russ, This sounds great (given that haven't been able to completely eliminate Windows from my life). Unfortunately, I can't seem to figure out quite what I need to do to install and/or build it so that acme works. The documentation at https://bitbucket.org/knieriem/pf9 confuses me, since it talks about running mk, but I can't find an mk executable in any of the downloads. Can you describe the steps you took to install/run it? i just ran the binaries in the downloads. i haven't tried to build anything. There are 5 downloads at https://bitbucket.org/knieriem/pf9/downloads. Which one(s) did you use? thanks, Peter Canning
[9fans] extern register
the amd64 compiler reserves R14 and R15 for extern register declarations. these are used by the kernel for the mach and up pointers, but currently are not preserved during system calls. would it make sense to save and restore the two registers on syscall entry/exit, so userspace programs could make use of them for per process data? -- cinap
Re: [9fans] extern register
On Fri Jul 18 21:58:37 EDT 2014, cinap_len...@felloff.net wrote: the amd64 compiler reserves R14 and R15 for extern register declarations. these are used by the kernel for the mach and up pointers, but currently are not preserved during system calls. would it make sense to save and restore the two registers on syscall entry/exit, so userspace programs could make use of them for per process data? i think after some experience (i.e. mistakes) the answer is probablly, no. the compiler needs to know for the kernel that r14 and r15 are special and not allocate them for the kernel, but what about userland? what about libraries that are shared between them? one can work around these problems by compiling all libraries twice, etc. but these are painful compromises. in reality, there is only one place in the code that i know of that chews through 15 or more registers, and that's the alpha drawing code in libmemdraw. so the solution of just limiting the compiler to r0-r13 seems to be pretty effective for what we're doing. - erik
Re: [9fans] extern register
On Fri Jul 18 22:05:32 EDT 2014, quans...@quanstro.net wrote: On Fri Jul 18 21:58:37 EDT 2014, cinap_len...@felloff.net wrote: the amd64 compiler reserves R14 and R15 for extern register declarations. these are used by the kernel for the mach and up pointers, but currently are not preserved during system calls. would it make sense to save and restore the two registers on syscall entry/exit, so userspace programs could make use of them for per process data? i think after some experience (i.e. mistakes) the answer is probablly, no. the compiler needs to know for the kernel that r14 and r15 are special and not allocate them for the kernel, but what about userland? what about libraries that are shared between them? one can work around these problems by compiling all libraries twice, etc. but these are painful compromises. in reality, there is only one place in the code that i know of that chews through 15 or more registers, and that's the alpha drawing code in libmemdraw. so the solution of just limiting the compiler to r0-r13 seems to be pretty effective for what we're doing. i realize i didn't quite answer the question as asked. restoring the registers is independent of the compiler. so yes, you're right! the registers should be restored. but at least you know why it's not a disaster that they are not. - erik
Re: [9fans] extern register
so, we say r14 and r15 arent really special for user programs. and its just a c compiler implementation detail that it doesnt allocate these registers, but assembly code can freely use them for scratch space or whatever. extern register will not work in userspace c programs because syscalls will trash these registers. makes any sense? -- cinap
Re: [9fans] extern register
isnt that contradicting what you just said? -- cinap
Re: [9fans] extern register
On Fri Jul 18 22:34:43 EDT 2014, cinap_len...@felloff.net wrote: isnt that contradicting what you just said? i didn't think so. restated: you could restore the registers, and that would be right proper, but it wouldn't make a difference unless you're using some fancy assembly, or a different compiler; it doesn't give the compiler more freedom. - erik
Re: [9fans] extern register
On Fri Jul 18 22:28:12 EDT 2014, cinap_len...@felloff.net wrote: so, we say r14 and r15 arent really special for user programs. and its just a c compiler implementation detail that it doesnt allocate these registers, but assembly code can freely use them for scratch space or whatever. extern register will not work in userspace c programs because syscalls will trash these registers. makes any sense? certainly. speaking for myself, the model that r14 and r15 are off limits for esoteric reasons is preferrable, given the quite limited maximum benefit, to the complications of sneaking by the limitation. obviously, the mips port avoided this by never needing 28 live registers at once. - erik
