Re: [9fans] Go Plan 9
On Tue, Apr 5, 2011 at 7:33 AM, Lucio De Re wrote: > No, and no "yuck", either: Go executables are different animals and > they are allowed to be identified as such. Until they are not, when > they are allowed to become the same animal. > snip... > > And maybe it's just me being uninformed, but I have this suspicion that > you need a Go toolchain with Plan 9 targets to produce Plan 9 executables. > Maybe I should phrase this as a question: does the default Go toolchain > produce Plan 9 executables or is a separate toolchain required for it? > I'm pretty certain there's a need for two toolchains, but I'll be very > happy to be proven wrong (and Ron right, of course). The vanilla Go distribution will produce ELF executables on Linux/FreeBSD/Darwin when the GOOS is set accordingly. If GOOS is set to plan9, 8l will produce a real Plan 9 a.out executable (it might complain it cannot find runtime and other packages unless you follow the procedure to build them). Pavel
Re: [9fans] Go Plan 9
>> The best answer might be to make USTKTOP 1GB. >> > Where? In 9vx. Russ
Re: [9fans] Go Plan 9
On Tue, Apr 05, 2011 at 01:11:35AM -0400, Russ Cox wrote: > > > All that Microsoft thinking (99.9%-thinking, if you find the other label > > offensive) to avoid adding a minute, one-off change to the Go runtime? > > It is not a minute, one-off change. I stand corrected. > I don't know how to fix it to cope with tiny virtual address spaces > like those in 9vx. It's not something I anticipated when I wrote the > allocator, and it's not something I really want to spend time on > for such a tiny fraction of use cases. We have limited time. > We don't even support OS X 10.5 anymore. > That is as good an answer as I could possibly ask for. There will be other eyes to look at it and hopefully supplement the lack of time. A quick, uneducated question: should 9vx be investigated instead? > The best answer might be to make USTKTOP 1GB. > Where? Thanks for replying. ++L
Re: [9fans] Go Plan 9
> All that Microsoft thinking (99.9%-thinking, if you find the other label > offensive) to avoid adding a minute, one-off change to the Go runtime? It is not a minute, one-off change. I don't know how to fix it to cope with tiny virtual address spaces like those in 9vx. It's not something I anticipated when I wrote the allocator, and it's not something I really want to spend time on for such a tiny fraction of use cases. We have limited time. We don't even support OS X 10.5 anymore. The best answer might be to make USTKTOP 1GB. Russ
Re: [9fans] Go Plan 9
> No, and no "yuck", either: Go executables are different animals and what's different about them? as far as i can tell, they're completely standard. - erik
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 04:33:29PM -0400, erik quanstrom wrote: > [ ... ] > then you can get rid of the old definitions in /*/include/u.h > and declare a flag day. having both seems wrong to me. > you might as well just do a local hack for the go stuff at that > point. > > the hard part is convincing everyone that this large > patch is worth the pain. > > i think it is, but maybe there's something i'm not > thinking of, or a different point of view. > Personally, I like the suggestion, but I think flag days in Plan 9 are best reserved for larger issues than the name of a handful of type definitions. The old type names might have been a bad choice (or a good choice, but contrary to popular opinion), but they do not need to go away, perhaps they can just be deprecated. I'm sure the label "wrong" is too strong. ++L
Re: [9fans] Go Plan 9
On Tue, Apr 05, 2011 at 12:22:18AM -0400, Russ Cox wrote: > The number of people who want to run Go on Plan 9 > is already small. The number of people who want to > run Go on Plan 9 on 9vx is smaller yet. At that point > why not just run Go directly? > All that Microsoft thinking (99.9%-thinking, if you find the other label offensive) to avoid adding a minute, one-off change to the Go runtime? Sure, as Ron suggested it, it may need some additional thought, but we are talking about the Plan 9 team thinking about it, surely it would not take long to solve? > 9vx is a nice hack but still a hack. > So is VMware, but it may be a breath of life for Plan 9 and adding features to it seems inexpensive enough. The same applies to p9p, which is another toolkit that could benefit from providing a development environment for Go. That said, I'd like to make it very clear that I am extremely grateful to all those who have contributed to making Go available on the Plan 9 platform and that I hope to be part of a growing community. The current solution to the 9vx problem seems adequate, one is merely concerned that it may come back to bite an unsuspecting third party if it is forgotten. ++L
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 04:10:15PM -0700, ron minnich wrote: > > On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re wrote: > > > May I suggest that we identify Go executables, because they may not run > > under 9vx, as different from Plan 9 executables and adjust the Plan 9 > > kernel to identify these and avoid running them under 9vx? > > > um, yuck :-) > > anyway, all you're saying is "don't run go on 9vx". That's a solved problem > :-) > No, and no "yuck", either: Go executables are different animals and they are allowed to be identified as such. Until they are not, when they are allowed to become the same animal. As for not running Go on 9vx, that's a pain, I have such a nice 9vx installation on my Ubuntu 32-bit laptop that it almost fools me into believing it's Plan 9. I don't always have a convenient CPU server at hand to run Go on it. And maybe it's just me being uninformed, but I have this suspicion that you need a Go toolchain with Plan 9 targets to produce Plan 9 executables. Maybe I should phrase this as a question: does the default Go toolchain produce Plan 9 executables or is a separate toolchain required for it? I'm pretty certain there's a need for two toolchains, but I'll be very happy to be proven wrong (and Ron right, of course). The proof would be in the pudding: I tried to compile hell-o.go (I guess that will become a benchmark :-) under an unadulterated Go toolchain, then under a Go toolchain built for the Plan 9 target (GOOS=plan9) and the object code produced showed distincly different sizes. I don't have the details at my fingertips now, this is from memory. And for Cinap, a challenge I wish I had the time and skills to take on myself: can linuxemu be added as a much thinner shim to 9vx to run Linux executables? I can think of one very interesting door that would open, there may be others. ++L
Re: [9fans] Go Plan 9
The number of people who want to run Go on Plan 9 is already small. The number of people who want to run Go on Plan 9 on 9vx is smaller yet. At that point why not just run Go directly? 9vx is a nice hack but still a hack. Russ
Re: [9fans] Go Plan 9
I tried a simple hack on 9vx. First, I had sysbrk_ return the max possible value instead of the requested value. I.e., if go runtime asked for 768MB, I had it return something less than TSTKTOP, which is around 256 MB. I like this because if we change the USTKTOP on 9vx in future we don't have to recompile the go runtime, and a single binary can run on many 9vx systems which might have different limits compiled in. Unfortunately the runtime code ignores the returned value from sbrk_; strike one. I then had it return -1 when asked for more memory than could be returned; Got this: term% ./testgo.out throw: and that was it. Russ, could the go runtime maybe use the value returned by sbrk instead of assuming it got all it asked for? ron
Re: [9fans] Patches for 9vx
I applied your patch for sprint to limit the size to 64k in 9vx. I'm still not sure I completely understand why it is needed on some systems (I accept the need for it however) but there is only so much time in the day and it's nice to have it working. ron
Re: [9fans] Go Plan 9
well, Russ has blessed the runtime fix :-) I look forward to having go in 9vx too! ron
Re: [9fans] Go Plan 9
> Sorry, Erik, I misunderstood your point. no need to be sorry. > I guess what you are pointing out is that on Plan 9, presumably, since > the Go runtime is the only thing that might call brk(), it will always > get a virtually contiguous heap. Therefore, instead of a huge upfront > allocation, Go runtime could call brk() as needed. > > Can we safely assume that only the Go runtime will call brk()? What if > we link a library into Go that calls brk() as well -- won't that > violate Go's model? Probably not worth worrying about since Russ says > he's good with the other change. i didn't think of that, but i wouldn't think one would want to do that. the effort, say, to glue ndb structures into go's world would seem on par with rewriting the library. and it would be a great oppertunity to clean up some crunch. one big challenge in gluing in c libraries is that you couldn't easily pass any sort of pointer back in from c. it would break the gc. - erik
Re: [9fans] Go Plan 9
On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re wrote: > May I suggest that we identify Go executables, because they may not run > under 9vx, as different from Plan 9 executables and adjust the Plan 9 > kernel to identify these and avoid running them under 9vx? um, yuck :-) anyway, all you're saying is "don't run go on 9vx". That's a solved problem :-) ron
Re: [9fans] Go Plan 9
On Mon, Apr 4, 2011 at 8:59 AM, erik quanstrom wrote: > this is the whole point of the big allocation, so why > would we drag this into plan 9, when it's not necessary. > the plan 9 heap is contiguous. Sorry, Erik, I misunderstood your point. I guess what you are pointing out is that on Plan 9, presumably, since the Go runtime is the only thing that might call brk(), it will always get a virtually contiguous heap. Therefore, instead of a huge upfront allocation, Go runtime could call brk() as needed. Can we safely assume that only the Go runtime will call brk()? What if we link a library into Go that calls brk() as well -- won't that violate Go's model? Probably not worth worrying about since Russ says he's good with the other change. thanks ron
Re: [9fans] Making read(1) an rc(1) builtin?
Unfortunately, echon.c doesn't solve the problem either, because it doesn't output a trailing newline. That's the whole point. 'echon' replaces 'echo -n ...', then echo.c loses all knowledge of any option flags. --lyndon
Re: [9fans] Making read(1) an rc(1) builtin?
> Unfortunately, echon.c doesn't solve the problem either, because it
> doesn't output a trailing newline. The crux of the problem is how to
> output "-n" on a line by itself, followed by a newline. I don't think
if you give me 2^n pennies for the nth way i can think of doing this,
i'm gonna be loaded
0. awk 'BEGIN{print "-n"; exit}'
1. echo x -n | sed 's/^ //'
2. echo print "-n\n" | hoc
3. echo '"-n
"' | bc
4. unicode 2d 6e | tr -d '\012' ; echo
5. echo '' -n | tr -d ' '
6. '-n' = 1; whatis -n | sed 's/=.*//'
> I'm trying to write an Acme client in rc(1). I'd like to avoid spawning
> a new read(1) process every time I make a keystroke or click the mouse.
> Using multi-line reads wouldn't help much, because interactivity needs
> to be maintained.
i don't know what your application is, you don't need to get
every mouseclick. see the Mail client.
- erik
Re: [9fans] Making read(1) an rc(1) builtin?
> I think this does a very good job of summing up the issue. I think the point > you might be missing, though, is that most of the Plan 9 community is quite > happy about the current state of things. You're likely right that > considerations > like this led to perl and bash - but rc's state is not an accident. We know > where to get perl and bash if we want them. we know where to get perl and bash, and obviously haven't. that ought to tell you something. there, fixed that for ya. > Put another way, your problem seems to be "I can't write an acme client in > rc with performance I'm happy with" (leaving aside, for the moment, > questions of measurement). Your solution is "expand rc"; I suspect the > consensus of the community would be either "deal with it" or "use C". > > Actually, that might be the consensus of the community on *most* issues. :-) i see this from a little different perspective. rc is a elegant, clean, easy-to-understand shell. none of these would hold if we threw in every feature we could think of. on the other hand, i don't think rc is the last word in shells. i think a new shell would be warmly received. i suppose one is needed every 20 years or so. unfortunately, it's not that easy. tom duff and sr bourne are pretty smart guys. you probablly won't outsmart them. but you are working with a more- capable system, you're free to ignore unix, and you do have the advantage of twenty years' experience with rc. good luck. - erik
Re: [9fans] Making read(1) an rc(1) builtin?
> ... creating a general-purpose Acme event parser in C. you may want to look at plan9port's acmeevent[1]. -- oleg [1] http://swtch.com/plan9port/man/man1/acmeevent.html
Re: [9fans] Making read(1) an rc(1) builtin?
On Apr 4, 2011, at 17:35, smi...@zenzebra.mv.com wrote: > All combined (forking read/test/echo, forking awk/sed/dd, parsing > /mnt/acme/%d/events, etc.)... this, I think, is why languages like Perl > came into existence and became so popular. I could definitely write an > Acme event parser in Perl, or even in bash(1). rc(1) is just a few > small features shy of making it practical to do in rc(1). I think this does a very good job of summing up the issue. I think the point you might be missing, though, is that most of the Plan 9 community is quite happy about the current state of things. You're likely right that considerations like this led to perl and bash - but rc's state is not an accident. We know where to get perl and bash if we want them. Put another way, your problem seems to be "I can't write an acme client in rc with performance I'm happy with" (leaving aside, for the moment, questions of measurement). Your solution is "expand rc"; I suspect the consensus of the community would be either "deal with it" or "use C". Actually, that might be the consensus of the community on *most* issues. :-) Anthony PGP.sig Description: This is a digitally signed message part
Re: [9fans] Making read(1) an rc(1) builtin?
roger peppe writes:
> when i've needed a "-n safe" version of echo in
> the past, i've used something like this:
>
> fn myecho {echo -n $"* ^ '
> '}
That doesn't work right when (~ $#* 0). It outputs a rogue space prior
to the newline. echo, with no arguments, should ouput just a newline.
"Lyndon Nerenberg (VE6BBM/VE7TFX)" writes:
>> (As a side note, if anyone goes into rc(1)'s source to implement any of
>> this, please add a "--" option (or similar) to the "echo" builtin while
>> you're there.
>
> Echo is not a builtin, and for one possible solution see
> /n/sources/contrib/lyndon/echon.c
Ah, you're right; echo isn't a builtin. I guess echo would be another
big candidate for elevation to "builtin" status, then.
Unfortunately, echon.c doesn't solve the problem either, because it
doesn't output a trailing newline. The crux of the problem is how to
output "-n" on a line by itself, followed by a newline. I don't think
it can be done symmetrically without adding another option to echo. It
can be done by wrapping "echo" in if/switch statement, but that violates
symmetry of invocation. Ideally, echo would be invokable like:
$ echo -n $foo # suppress newline
$ echo -y $foo # force newline
$ echo $foo# newline by default
erik quanstrom writes:
> could you be concrete about your performance problem.
> if you don't have a performance problem, then there's no
> point to optimizing.
I'm trying to write an Acme client in rc(1). I'd like to avoid spawning
a new read(1) process every time I make a keystroke or click the mouse.
Using multi-line reads wouldn't help much, because interactivity needs
to be maintained.
I'm using rc(1) because the /mnt/acme/%d/events interface is
well-documented (in /sys/doc/acme/acme.ps), but the C code under
/acme/bin/source/ for reading /mnt/acme/%d/events it is definitively
cryptic. I've managed to peel away the extra layers of code from one of
the simpler Acme clients, in /acme/bin/source/adict/win.c, and am in the
process of creating a general-purpose Acme event parser in C. The
output of the filter will be in a form easily digestible by scripts, and
would provide a good "skeleton" example of event parsing for other
coders to build upon. (There doesn't currently appear to be any such
"starter code" under /acme/bin/source or /sys/doc.)
If only Acme put a single extra space immediately prior the first
integer (c0) in it's event messages, this parsing could have been done
almost entirely within rc(1).
I know that using awk(1) is a possibility, but awk(1) still has to
system() every "test -e", just like rc(1) does. I would use scheme, but
the scheme in fgb's contrib doesn't seem to provide any way of
stat(2)ing path names without resorting to its foreign function
interface. :(
All combined (forking read/test/echo, forking awk/sed/dd, parsing
/mnt/acme/%d/events, etc.)... this, I think, is why languages like Perl
came into existence and became so popular. I could definitely write an
Acme event parser in Perl, or even in bash(1). rc(1) is just a few
small features shy of making it practical to do in rc(1).
--
+---+
|E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---+
Re: [9fans] Go Plan 9
> term% diff /n/dump/2011/0130/386/include/u.h /n/dump/2011/0404/386/include/u.h
> 21a22,34
> > /* for the GO toolchain */
> > /* (with some effort this could go into /go/386/include,
> > but there's really no reason to keep it from the
> > native toolchain)
> > */
> > typedef char int8;
> > typedef short int16;
> > typedef long int32;
> > typedef long long int64;
> > typedef unsigned char uint8;
> > typedef unsigned short uint16;
> > typedef unsigned long uint32;
> > typedef unsigned long long uint64;
>
> Seems harmless enough. I'm sure I've actually rebuilt the Plan 9 binaries
> in their entirety with these changes and no ill effect.
that part is easy enough. and this part is easy enough, too
{
# will get quoted instances, too
echo X ,x:[a-zA-Z_][a-zA-Z_0-9]*: v/.../
s/u(8|16|32|64)int/uint\1/g
echo X ,x:[a-zA-Z_][a-zA-Z_0-9]*: v/.../
s/s(8|16|32|64)int/int\1/g
echo w
ecgi q
} | sam -d `{find /sys/src|grep '\.[chy]$'
then you can get rid of the old definitions in /*/include/u.h
and declare a flag day. having both seems wrong to me.
you might as well just do a local hack for the go stuff at that
point.
the hard part is convincing everyone that this large
patch is worth the pain.
i think it is, but maybe there's something i'm not
thinking of, or a different point of view.
- erik
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 07:27:28PM +0200, Lucio De Re wrote: > On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote: > > > > Thanks for the detailed explanation, I've added your patch to if that > > is alright with you https://bitbucket.org/paulzhol/golang-plan9- > > runtime-patches/ > > > [ ... ] > > The other one I would like to submit as a patch affects /386/include/u.h > (and other architectures), involving the addition of integer types of > various length. Equally small and benign. > > Opinions? > Here is how I changed u.h for the 386 architecture: term% diff /n/dump/2011/0130/386/include/u.h /n/dump/2011/0404/386/include/u.h 21a22,34 > /* for the GO toolchain */ > /* (with some effort this could go into /go/386/include, > but there's really no reason to keep it from the > native toolchain) > */ > typedef char int8; > typedef short int16; > typedef long int32; > typedef long long int64; > typedef unsigned char uint8; > typedef unsigned short uint16; > typedef unsigned long uint32; > typedef unsigned long long uint64; Seems harmless enough. I'm sure I've actually rebuilt the Plan 9 binaries in their entirety with these changes and no ill effect. ++L
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 10:18:12PM +0300, Pavel Zholkover wrote: > On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re wrote: > > PS: Would anybody like to summarise for us plebs whether there is any > > convergence looming between Go and Plan 9 on the x64 front? It seems > > sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit > > toolchain to Plan 9. > > the basic runtime support (not the current syscall and os changes) > involved changes to 8l and some C and 386 specific assembly in > pkg/runtime. I guess this could be re-done for 6l + x64 code in > runtime. The question is whether it is a useful application of > developers time at this stage (it would be still cross-compiled) and > the 386 runtime has not been properly tested. > I agree that focussing on x64 when there isn't a working target would be pointless, if intriguing. I guess the question then belongs in the Plan 9 camp: are we going to see an x64 Plan 9 development soon? and is the availability of the 6? chain in the Go sources helpful in arriving there? ++L
Re: [9fans] Go Plan 9
[Sorry for being quiet, I got unsubscribed from 9fans!] > no, the shared libraries are not going to affect the heap size. > Certainly not to this scale. > > My understanding was that Go used this large sparse address space to > effect for its garbage collection; the fact that it is backed by mmap > of anonymous memory is what makes it work, since pages are not > allocated until touched. Russ? The large sparse address space is nice on 64-bit because you can do some address calculation tricks. On 32-bit it just doesn't matter. I think the current code in package runtime is correct already for Plan 9. Russ
Re: [9fans] Go Plan 9
On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re wrote: > PS: Would anybody like to summarise for us plebs whether there is any > convergence looming between Go and Plan 9 on the x64 front? It seems > sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit > toolchain to Plan 9. the basic runtime support (not the current syscall and os changes) involved changes to 8l and some C and 386 specific assembly in pkg/runtime. I guess this could be re-done for 6l + x64 code in runtime. The question is whether it is a useful application of developers time at this stage (it would be still cross-compiled) and the 386 runtime has not been properly tested. Pavel
Re: [9fans] Go Plan 9
On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote: > > Thanks for the detailed explanation, I've added your patch to if that > is alright with you https://bitbucket.org/paulzhol/golang-plan9- > runtime-patches/ > May I suggest that we identify Go executables, because they may not run under 9vx, as different from Plan 9 executables and adjust the Plan 9 kernel to identify these and avoid running them under 9vx? There will be changes to Plan 9 to match the Go toolchain, this one is really small and could be seen as acceptance of Go as part of Plan 9's future. Ideally, when the Go runtime no longer needs special treatment we can re-categorise Go executables as normal Plan 9 executables. That option moves into the hands of the Go developers, which to me seems like the right place. The other one I would like to submit as a patch affects /386/include/u.h (and other architectures), involving the addition of integer types of various length. Equally small and benign. Opinions? ++L PS: Would anybody like to summarise for us plebs whether there is any convergence looming between Go and Plan 9 on the x64 front? It seems sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit toolchain to Plan 9.
Re: [9fans] more "Plan 9 from Bell Labs" questions
On Mon Apr 4 11:54:45 EDT 2011, eeke...@fastmail.fm wrote: > > On 4 Apr 2011, at 9:36 am, faif wrote: > > > > "Using streams to implement network interfaces in the kernel allows > > protocols to be connected together dynamically, such as to attach the > > same TTY driver to TCP, URP, and IL connections, but Plan 9 makes no > > use of this configurability." > > This one makes no sense to me. TTY driver... network interface? If > those two things make sense together, it still makes no sense to put > them both together in the Plan 9's kernel, I'm sure. plan 9 is fairly unique in that a file server can just as easily be in the kernel, or in user space, or on another machine; and a device driver is nothing more than a file server. put 'em all in the kernel for purely parsimonious reasons doesn't make too much sense to me. but that's just in theory. in practice, it's been easiest, simplist and fastest to put most hw drivers in the kernel. by the way, you can plug file servers together regardless of where they live. kernel, user space, another machine. it matters not. - erik
Re: [9fans] Go Plan 9
On Mon Apr 4 11:19:37 EDT 2011, rminn...@gmail.com wrote: > On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom > wrote: > >> The reason it doesn't work on 9vx is because the 32 bit Go runtime > >> reserves a large chunk of address space (currently 768mb). On all > >> other platforms, this is accomplised with an mmap equivalient, which > >> we all know won't work on Plan 9. > >> > > > > if i read the thread on this topic correctly, this reservation > > isn't necessary on plan 9, since there are no shared libraries > > and the heap will always be contiguous. > > > > no, the shared libraries are not going to affect the heap size. > Certainly not to this scale. > i'm not quite sure what you're saying "no" to. in any event, my understanding is, it's not the size of the heap, it's the heap's continuity. if the heap is not contiguous, you'll need a structure tracking it. according to lwn http://lwn.net/Articles/428100/ In the process of trying to reach that goal of "low enough overhead and no significant latency," the Go developers have made some simplifying assumptions, one of which is that the memory being managed for a running application comes from a single, virtually-contiguous address range. this is the whole point of the big allocation, so why would we drag this into plan 9, when it's not necessary. the plan 9 heap is contiguous. - erik
Re: [9fans] more "Plan 9 from Bell Labs" questions
On 4 Apr 2011, at 9:36 am, faif wrote: "Using streams to implement network interfaces in the kernel allows protocols to be connected together dynamically, such as to attach the same TTY driver to TCP, URP, and IL connections, but Plan 9 makes no use of this configurability." This one makes no sense to me. TTY driver... network interface? If those two things make sense together, it still makes no sense to put them both together in the Plan 9's kernel, I'm sure.
Re: [9fans] Go Plan 9
On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom wrote: >> The reason it doesn't work on 9vx is because the 32 bit Go runtime >> reserves a large chunk of address space (currently 768mb). On all >> other platforms, this is accomplised with an mmap equivalient, which >> we all know won't work on Plan 9. >> > > if i read the thread on this topic correctly, this reservation > isn't necessary on plan 9, since there are no shared libraries > and the heap will always be contiguous. > no, the shared libraries are not going to affect the heap size. Certainly not to this scale. My understanding was that Go used this large sparse address space to effect for its garbage collection; the fact that it is backed by mmap of anonymous memory is what makes it work, since pages are not allocated until touched. Russ? ron
Re: [9fans] more "Plan 9 from Bell Labs" questions
On Mon, Apr 4, 2011 at 11:36 AM, faif wrote: > "9P has two forms: RPC messages sent on a pipe or network connection > and a procedural interface within the kernel. Since kernel device > drivers are directly addressable, there is no need to pass messages to > communicate with them;" > > Are the device drivers really in kernel space? It seems that Plan 9 is > an ideal design for moving buggy software like 3rd party drivers into > the user space. > Some of them are. Vga is, for example, usb is half in (usbd), half out (usb/disk). Whenever possible it is better to have things in user space (protection, easy to debug, etc). Sometimes for efficiency reasons it is better inside (less context switches, no marshalling of 9P etc.). > Just wondering if anybody has worked on the TODO things mentioned in > the paper: > > "Using streams to implement network interfaces in the kernel allows > protocols to be connected together dynamically, such as to attach the > same TTY driver to TCP, URP, and IL connections, but Plan 9 makes no > use of this configurability." > I am guessing this is why there are no streams any more :-). > "Although Plan 9 has per-process name spaces, it has no mechanism to > give the description of a process’s name space to another process > except by direct inheritance." > > There is no way to do this now in plan 9 as it is AFAIK. The best you can try to do is get the namespace /proc/*/ns and try to recreate it which is not exactly the same. G.
[9fans] more "Plan 9 from Bell Labs" questions
"9P has two forms: RPC messages sent on a pipe or network connection and a procedural interface within the kernel. Since kernel device drivers are directly addressable, there is no need to pass messages to communicate with them;" Are the device drivers really in kernel space? It seems that Plan 9 is an ideal design for moving buggy software like 3rd party drivers into the user space. Just wondering if anybody has worked on the TODO things mentioned in the paper: "Using streams to implement network interfaces in the kernel allows protocols to be connected together dynamically, such as to attach the same TTY driver to TCP, URP, and IL connections, but Plan 9 makes no use of this configurability." "Although Plan 9 has per-process name spaces, it has no mechanism to give the description of a process’s name space to another process except by direct inheritance."
Re: [9fans] Making read(1) an rc(1) builtin?
On 4 April 2011 03:53, erik quanstrom wrote:
> i think this is what you want
>
> for(line in `{ifs=$nl cat}){...}
no, because that only sets ifs for the cat command, not
for the `{} construct.
ifs=$nl for (line in `{cat}) { ... }
is perhaps what you meant to say.
> but i have no idea why one would avoid the read
> idiom. for large input, forking off a read for each
> line keeps the memory footprint O(1).
FWIW, i think that avoiding a read(1) loop is
perfectly reasonable thing to want to do.
a quick test i measured that calling read in
shell loop was about 100 times slower than
using `{}, and about 500 times slower than
using awk to read the lines.
in general, unless it was truly necessary, i would
try to use awk or sed rather than use read(1) in
a loop when i was going to deal with significantly
sized input.
when i've needed a "-n safe" version of echo in
the past, i've used something like this:
fn myecho {echo -n $"* ^ '
'}
[9fans] advice and advice
i'm doing a cross the Himalayas by bunnie. so my advice is if anyone wants to tag along it's july 17th. i'm fitting out the support jeep (all else are on mad motobikes) and i'm having problems with accelerometers. the ones i've tried either jitter inanely or go erratic. any experience / advice? and i need a 2nd tech so i can sleep. cinap? brucee
Re: [9fans] Making read(1) an rc(1) builtin?
(right, sorry erik for the double)
> i hate to be pedantic,
By all means, please be pedantic, I was flat wrong.
>ifs is not a list; it is a set of characters like strpbrk(2).
And it matches [$ifs]+ which is the other piece I always forget.
> for(line in `{ifs=$nl cat}){...}
That is exactly what I was saying, thank you. That's what I get for
spending the last few days writing in php, sigh.
> as per plan 9 tradition, the first non-option terminates
> option processing. lindon's echon is not required. giving
> echo -n as its first argument works fine.
What I thought smiley was referring to is when the first argument is
inteded to output -n, but doesn't. What I gave obviously puts an extra
space in (I guess I was a bit fuzzy earlier), echo -n $it^$nl works if
$it is not a list. I've never seen this be a problem in practice myself.
--
All original matter is hereby placed immediately under the public domain.
Re: [9fans] Go Plan 9
Thanks for the detailed explanation, I've added your patch to if that
is alright with you https://bitbucket.org/paulzhol/golang-plan9-
runtime-patches/
Pavel
On Mon, Apr 4, 2011 at 1:30 AM, Anthony Martin wrote:
> Pavel Zholkover once said:
>> I'm not sure I understand the reason 9vx will fail to reserve 768mb
>> with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
>> fine, as long as it is not written to.
>
> The reason is because 9vx gives user processes a virtual
> address space of only 256mb. The brk works but the
> first time we fault one of those pages past USTKTOP the
> program suicides.
>
> The first fault happens at src/pkg/runtime/mcache.c:21
> in the runtime·MCache_Alloc function.
>
> To show you what I mean, here's a formatted stack trace:
>
> term% cat y.go
> package main
>
> func main() {
> println("Hello, world.")
> }
>
> term% ./8.out
> 8.out 174: suicide: sys: trap: page fault pc=0x21df
>
> term% db 8.out 174
> 386 binary
> page fault
> /go/src/pkg/runtime/mcache.c:21 runtime.MCache_Alloc+39/ MOVL
> 0(AX),AX
> $c
> runtime.MCache_Alloc(sizeclass=0x1, c=0x30424000, size=0x8, zeroed=0x1)
> /go/src/pkg/runtime/mcache.c:13 called from runtime.mallocgc+db
> /go/src/pkg/runtime/malloc.goc:62
> runtime.mallocgc(size=0x8, zeroed=0x1, flag=0x0, dogc=0x0)
> /go/src/pkg/runtime/malloc.goc:40 called from runtime.malloc+41
> /go/src/pkg/runtime/malloc.goc:115
> runtime.malloc(size=0x1)
> /go/src/pkg/runtime/malloc.goc:113 called from runtime.mallocinit+e9
> /go/src/pkg/runtime/malloc.goc:319
> runtime.mallocinit()
> /go/src/pkg/runtime/malloc.goc:237 called from runtime.schedinit+39
> /go/src/pkg/runtime/proc.c:122
> runtime.schedinit()
> /go/src/pkg/runtime/proc.c:113 called from _rt0_386+b3
> /go/src/pkg/runtime/386/asm.s:78
> _rt0_386()
> /go/src/pkg/runtime/386/asm.s:12 called from 1
>
>
> Cheers,
> Anthony
>
>
