[9fans] plan9 packages
Hi, Can I suggest that when ken's fs is split from the main plan9 tree it is not tar'ed up but it is just copied to a source tree which contains only the kenfs stuff but in their correct places in a plan9 hierarchy, and a replica proto generated for it. The idea is that the new owner(s) of the kenfs tree could be given write permission to the code and then those who want to continue to use it could get the latest changes by doing somthing like: bind -a /n/sources/plan9/replica /n/sources/extra/kenfs/replica replica/pull kenfs We would lose nothing as the last supported release of kenfs will allways be available in sourcesdump. I would be willing to try to do the same work with some of the other tars in the contrib area (x11, tex etc) I do understand the danger that we might end up with somthing like the debian package managment stuff However it would be great to have an easy way to grab an arbitary package and keep it up to date. I recently fixed a silly bug in cvsfs but it doesn't really seem worthwhile emailing the whole list. It would also be great if the packages had some sport of Author file so people could submit patches against them and the relevant person/people would get the patch email. What do people think, neat idea or the thin end of the wedge? -Steve
Re: [9fans] sources access from brazil
hello i can't connect now from Spain :) mount/attach disallowed sdls. gabi On 9/2/07, Iruata Souza [EMAIL PROTECTED] wrote: On 9/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It should work now. Brazil's whois server produces non-standard output, so we have to recognise it specially, and the output format has changed since we last adapted to it. still the same: I can't connect from Rio de Janeiro but it's ok for a friend in Belo Horizonte. iru
Re: [9fans] Re: everything is a directory
On 9/2/07, Joel C. Salomon [EMAIL PROTECTED] wrote: On 9/1/07, Uriel [EMAIL PROTECTED] wrote: With this way of thinking we will never catch up with lunix's 400 syscalls (and counting, not to mention the ioctls)! We're partly there in spirit; what fraction of the 4e kernel's system calls are there for backwards compatibility? ;) Back on topic, I wasn't proposing a readdir() syscall but pointing out that Douglas's suggestion would not in fact be painless or transparent under Plan 9. Indeed, and I would say that is a feature, not a bug. (Adding an extra syscall to read dirs would be a bug). But maybe my sarcasm got lost along the way. And actually, I think one could have something similar to Douglas suggestion in Plan 9 without changing the kernel or the vfs, or even the file servers, just have a stackable file server which for every original file /foo.txt allows you to access a /[EMAIL PROTECTED]/ dir where all the extended attributes or whatever can live, that would even keep backwards compatibility with all existing tools (tools that don't know about @extendedjunk/ dirs would not even see them unless they explicitly walk to them, so you could use cd /[EMAIL PROTECTED]/, followed of ls and cat to inspect the attributes, but if you do cat /* or ls / you would get a sensible output. Anyway, I still think it would be a waste of time, but like unix in its day, plan9 makes adding new 'features' rather easy, whatever they are worthy or another symlink-hell awaiting to happen is another question. Best wishes uriel P.S.: The Plan 9 industry is not creating enough jobs, we need more syscalls! And dynamic linking!
Re: [9fans] sources access from brazil
hello it works now again thanks gabi On 9/2/07, Gabriel Diaz [EMAIL PROTECTED] wrote: hello i can't connect now from Spain :) mount/attach disallowed sdls. gabi On 9/2/07, Iruata Souza [EMAIL PROTECTED] wrote: On 9/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It should work now. Brazil's whois server produces non-standard output, so we have to recognise it specially, and the output format has changed since we last adapted to it. still the same: I can't connect from Rio de Janeiro but it's ok for a friend in Belo Horizonte. iru
Re: [9fans] Re: everything is a directory
On 9/2/07, Uriel [EMAIL PROTECTED] wrote: And actually, I think one could have something similar to Douglas suggestion in Plan 9 without changing the kernel or the vfs, or even the file servers, just have a stackable file server which for every original file /foo.txt allows you to access a /[EMAIL PROTECTED]/ dir where all the extended attributes or whatever can live, that would even keep backwards compatibility with all existing tools (tools that don't know about @extendedjunk/ dirs would not even see them unless they explicitly walk to them, so you could use cd /[EMAIL PROTECTED]/, followed of ls and cat to inspect the attributes, but if you do cat /* or ls / you would get a sensible output. Or how about this: Just as you don't need read permissions on a directory to walk it -- so long as you know the name of the file you want -- how about 9p allowing walks to ordinary files. /foo.txt will exist, and reads work as usual, but /foo.txt/metadata.xml (of course it's all buzzword-compliant XML!) can be walked to and manipulated. Disgusting, eh? --Joel
Re: [9fans] sources access from brazil
If you think you're being denied access incorrectly, please include your IP address(es) in your mail to us. The mostly likely cause is that we can't reach a whois server.
Re: [9fans] plan 9 overcommits memory?
this means that the malloc *succeeded* it wasn't until i forced the pagefault with the memset that i ran out of memory. what's going on here? you know what's going on here. read the subject you wrote. the problem is not really as easy as it might seem at first. malloc just moves the brk, but the backing pages don't get allocated until the pages are accessed (during memset). you could argue for some kind of accounting that would ensure pages were available, but this could only be terribly pessimistic, especially in the case of stacks and fork. russ
Re: [9fans] plan 9 overcommits memory?
the problem is not really as easy as it might seem at first. malloc just moves the brk, but the backing pages don't get allocated until the pages are accessed (during memset). i'm just suprised that plan 9 overcommits. this makes this code nonsensical from user space if((p = malloc(Size)) == 0) /* malloc recovery code */ /* why bother? the kernel could be lying to us anyway. */ also, by default plan 9 assumes that there are 16 MB of memory more than actually exist. i would think with today's large memories typically, one would want to assume the worst and underestimate the amount of memory required so malloc would fail rather than getting a page fault later. you could argue for some kind of accounting that would ensure pages were available, but this could only be terribly pessimistic, especially in the case of stacks and fork. how pessimistic would this be? i'll gladly trade a substantial chunk of memory for failure on allocation rather than failure on access. - erik
Re: [9fans] plan 9 overcommits memory?
but most people can live with the overcommit, as witness the fact that most of us do and never know it. If you can't live with overcommit, maybe you need a wrapper that: sets up to catch the note (I am assuming here that you get one; do you?) malloc zero memory you malloc'ed (which will get the pages in) die reasonably if you get the note Would that work? ron
Re: [9fans] plan 9 overcommits memory?
but most people can live with the overcommit, as witness the fact that most of us do and never know it. If you can't live with overcommit, maybe you need a wrapper that: sets up to catch the note (I am assuming here that you get one; do you?) malloc zero memory you malloc'ed (which will get the pages in) die reasonably if you get the note but why introduce unpredictability? who really programs as if memory is not overcommited? i would bet that acme and most residents of /sys/src/cmd could do quite bad things to you in these cases. there's no waserror() in userland to wrap around memset. how much memory can be wasted by assuming that all brk'ed memory can be used? - erik
Re: [9fans] plan 9 overcommits memory?
but most people can live with the overcommit, as witness the fact that most of us do and never know it. If you can't live with overcommit, maybe you need a wrapper that: sets up to catch the note (I am assuming here that you get one; do you?) malloc zero memory you malloc'ed (which will get the pages in) die reasonably if you get the note but why introduce unpredictability? who really programs as if memory is not overcommited? i would bet that acme and most residents of /sys/src/cmd could do quite bad things to you in these cases. there's no waserror() in userland to wrap around memset. how much memory can be wasted by assuming that all brk'ed memory can be used? - erik
Re: [9fans] sources access from brazil
This is probably a silly question, but why should anyone be denied access on the basis of whatever a whois server who knows where might or might not do? Best wishes and thanks for fixing the issues iru was having. uriel On 9/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If you think you're being denied access incorrectly, please include your IP address(es) in your mail to us. The mostly likely cause is that we can't reach a whois server.
Re: [9fans] sources access from brazil
Uriel, As long as Plan 9 is hosted in the US and contains certain software it's illegal to export to certain countries(IIRC North Korea, Iran etc...). To stay on the right side of American law Geoff and gang have to do it that way. Noah On 9/3/07, Uriel [EMAIL PROTECTED] wrote: This is probably a silly question, but why should anyone be denied access on the basis of whatever a whois server who knows where might or might not do? Best wishes and thanks for fixing the issues iru was having. uriel On 9/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If you think you're being denied access incorrectly, please include your IP address(es) in your mail to us. The mostly likely cause is that we can't reach a whois server.
Re: [9fans] sources access from brazil
I'm sorry, but that makes no sense at almost every level: 1) why would whois info matter to determine where a client is? There are databases of ip country locations which would make much more sense, depending on notoriously unreliable whois servers is silly both from a security point of view and from a reliability point of view. 2) are you saying that http://groups.google.com/group/plan9changes, kernel.org or lkml are illegal? (or prety much any site that hosts linux ISOs) 3) this is hardly surprising given how totally unenforceable any such laws might be, anyone can import /net from tip9ug, or use a random http proxy and make the whole thing pointless (other than keeping out people like iru). I might be stupid, but this still makes no sense to me, and I would like to know why nobody else seems to have any such problems. Best wishes uriel P.S.: Note the following notice in kernel.org: Due to U.S. Exports Regulations, all cryptographic software on this site is subject to the following legal notice: This site includes publicly available encryption source code which, together with object code resulting from the compiling of publicly available source code, may be exported from the United States under License Exception TSU pursuant to 15 C.F.R. Section 740.13(e). This legal notice applies to cryptographic software only. Please see the Bureau of Industry and Security for more information about current U.S. regulations. On 9/3/07, Noah Evans [EMAIL PROTECTED] wrote: Uriel, As long as Plan 9 is hosted in the US and contains certain software it's illegal to export to certain countries(IIRC North Korea, Iran etc...). To stay on the right side of American law Geoff and gang have to do it that way. Noah On 9/3/07, Uriel [EMAIL PROTECTED] wrote: This is probably a silly question, but why should anyone be denied access on the basis of whatever a whois server who knows where might or might not do? Best wishes and thanks for fixing the issues iru was having. uriel On 9/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If you think you're being denied access incorrectly, please include your IP address(es) in your mail to us. The mostly likely cause is that we can't reach a whois server.
Re: [9fans] plan 9 overcommits memory?
If system calls were the only way to change memory allocation, one could probably keep a strict accounting of pages allocated and fail system calls that require more VM than is available. But neither Plan 9 nor Unix works that way. The big exception is stack growth. The kernel automatically extends a process's stack segment as needed. On the pc, Plan 9 currently limits user-mode stacks to 16MB. On a CPU server with 200 processes (fairly typical), that's 3.2GB of VM one would have to commit just for stacks. With 2,000 processes, that would rise to 32GB just for stacks.
Re: [9fans] plan 9 overcommits memory?
On Sun, Sep 02, 2007 at 11:38:44PM -0400, [EMAIL PROTECTED] wrote: would have to commit just for stacks. With 2,000 processes, that would rise to 32GB just for stacks. With 4GB RAM, wouldn't you allocate at least that much swap no matter what?
