http://codereview.appspot.com/3816043/diff/9001/src/pkg/os/env_plan9.go File src/pkg/os/env_plan9.go (right): http://codereview.appspot.com/3816043/diff/9001/src/pkg/os/env_plan9.go#newcode131 src/pkg/os/env_plan9.go:131: } You said "runtime support for getenv is missing", ...
14 years, 2 months ago
(2010-12-30 01:29:32 UTC)
#3
Thanks for the review and happy new year! Pavel http://codereview.appspot.com/3816043/diff/9001/src/pkg/os/env_plan9.go File src/pkg/os/env_plan9.go (right): http://codereview.appspot.com/3816043/diff/9001/src/pkg/os/env_plan9.go#newcode131 src/pkg/os/env_plan9.go:131: ...
14 years, 2 months ago
(2010-12-31 13:11:13 UTC)
#4
Thanks for the review and happy new year!
Pavel
http://codereview.appspot.com/3816043/diff/9001/src/pkg/os/env_plan9.go
File src/pkg/os/env_plan9.go (right):
http://codereview.appspot.com/3816043/diff/9001/src/pkg/os/env_plan9.go#newco...
src/pkg/os/env_plan9.go:131: }
I meant runtime·getenv is not doing the right thing for Plan 9. It goes over the
os.Envs slice which is always empty, instead of reading the filesystem provided
by a special device which is exporting the environment ('#e/').
I'm not sure adding os.init() is the right solution because runtime·getenv is
called very early, in runtime·schedinit for exmple.
I just didn't have the chance to code it in C for runtime yet.
On 2010/12/30 01:29:32, brainman wrote:
> You said "runtime support for getenv is missing", if you mean that os.Env is
not
> initialized, then just add this:
>
> func init() {
> Envs = Environ()
> }
>
> os.Args should already be set by runtime.
http://codereview.appspot.com/3816043/diff/9001/src/pkg/os/file_posix.go
File src/pkg/os/file_posix.go (right):
http://codereview.appspot.com/3816043/diff/9001/src/pkg/os/file_posix.go#newc...
src/pkg/os/file_posix.go:7: package os
My mistake, will fix.
On 2010/12/30 01:29:32, brainman wrote:
> You should do "hg cp ..." instead of "hg add ..." for that file (and others),
to
> retain change history.
http://codereview.appspot.com/3816043/diff/9001/src/pkg/syscall/asm_plan9_386.s
File src/pkg/syscall/asm_plan9_386.s (right):
http://codereview.appspot.com/3816043/diff/9001/src/pkg/syscall/asm_plan9_386...
src/pkg/syscall/asm_plan9_386.s:18: // slide args down on top of system call
number
I think that in 8g the caller expects the results to be in the first location
right after the arguments which means they are first on the stack - so you can't
adjust the return address (and this is also the way FreeBSD is doing it).
On 2010/12/30 01:29:32, brainman wrote:
> Just an optimization: you could achieve the same by just adjusting SP by 4 and
> moving return address one word up. Same for Syscall6.
http://codereview.appspot.com/3816043/diff/9001/src/pkg/syscall/asm_plan9_386...
src/pkg/syscall/asm_plan9_386.s:68: // call errstr with buffer on the stack
You are right about the segmented stacks, I totally forgot about them.
I had an extra slice argument I passed in earlier versions, but because I always
had to take the address of the slice with unsafe.Pointer, 8g would always
allocate it on the heap for each syscall.
I don't know if it is alright to call a function which can grow its stack from
inside one that is not doing the checks, but I'll move these bits into errstr()
in syscall_paln9.go.
On 2010/12/30 01:29:32, brainman wrote:
> I would be careful here - you're running on "go stack". You can't assume there
> is infinite amount of space on stack. In fact, this function, being (#pragma
> textflag 7), is not checking if it needs to grow stack at the start, therefore
> it becomes your responsibility.
>
> There is too much happening here anyway, I would implement it in C or Go
> instead: just pass ready to use buffer for the error string to your asm
function
> and parse it in C/Go once it returns.
http://codereview.appspot.com/3816043/diff/9001/src/pkg/syscall/syscall.go
File src/pkg/syscall/syscall.go (left):
http://codereview.appspot.com/3816043/diff/9001/src/pkg/syscall/syscall.go#ol...
src/pkg/syscall/syscall.go:16: func Syscall(trap, a1, a2, a3 uintptr) (r1, r2,
err uintptr)
Oops, this was left over from one of the earlier attempts. I think I call
Syscall only once anyway. I'll revert it back.
On 2010/12/30 01:29:32, brainman wrote:
> I'm not sure, you should change signature of all these functions. You're not
> calling these functions by hand, but generate all calls automagically - you
> could ignore some return values, if they are not used.
>
> If you insist on that change, please copy these lines into syscall_windows.go
> the way you copied them into syscall_unix.go, otherwise windows build fails.
14 years, 2 months ago
(2011-01-03 23:12:19 UTC)
#6
LGTM
http://codereview.appspot.com/3816043/diff/28001/src/pkg/syscall/syscall_plan...
File src/pkg/syscall/syscall_plan9.go (right):
http://codereview.appspot.com/3816043/diff/28001/src/pkg/syscall/syscall_plan...
src/pkg/syscall/syscall_plan9.go:336: func errstr() string {
I would:
func SyscallErrstrAsm(trap, a1, a2, a3 uintptr, ebuf *byte, ebuflen uint32) (r
uintptr)
func SyscallErrstr(trap, a1, a2, a3 uintptr) (r uintptr, err string) {
b := make([]byte, ERRMAX)
r = SyscallErrstrAsm(trap, a1, a2, a3, &b[0], uint32(len(b)))
if b[0] == 0 {
return r, ""
}
b[len(b)-1] = 0
return r, string(b[:findnull(b)])
}
This way you don't need to call back from asm to go. Also you don't need to copy
errstr from buffer to buffer in asm.
On 2011/02/09 05:27:37, rsc wrote: > no hurry; just wanted to note that i'm > ...
14 years, 1 month ago
(2011-02-09 09:07:35 UTC)
#12
On 2011/02/09 05:27:37, rsc wrote:
> no hurry; just wanted to note that i'm
> waiting for syscall to be split into a different
> CL before reviewing this.
Done, os changes are in http://codereview.appspot.com/4149046/.
Thanks for the review! Please take another look. http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/exec_plan9.go File src/pkg/syscall/exec_plan9.go (right): http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/exec_plan9.go#newcode99 src/pkg/syscall/exec_plan9.go:99: r1, ...
14 years, 1 month ago
(2011-02-10 08:41:39 UTC)
#14
Thanks for the review! Please take another look.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/exec_plan9.go
File src/pkg/syscall/exec_plan9.go (right):
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/exec_plan9....
src/pkg/syscall/exec_plan9.go:99: r1, _, _ = RawSyscall(SYS_RFORK,
uintptr(RFPROC|RFFDG|RFREND|clearenv), 0, 0)
On 2011/02/09 19:50:19, ality wrote:
> You should check if the rfork fails.
I've added an r1 == -1 test, but I'm not sure I can get the errstr here because
this is still running in the parent process with threads and locks. Can I safely
use SyscallErrstr here ?
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/exec_plan9....
src/pkg/syscall/exec_plan9.go:119: r1, _, _ = RawSyscall(SYS_CREATE,
uintptr(unsafe.Pointer(envv[i].name)), uintptr(O_WRONLY), uintptr(0666))
On 2011/02/09 19:50:19, ality wrote:
> I would split this chunk of code into
> a setenv function so the error handling
> is easier to understand.
We are inside forkAndExecInChild after an rfork, therefore we cannot grow
stack/allocate memory. I would have to code setenv in C with #pragma textflag 7
set.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/exec_plan9....
src/pkg/syscall/exec_plan9.go:224: const (
On 2011/02/09 19:50:19, ality wrote:
> Get rid of the parens in the const expression.
Done.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/mkall.sh
File src/pkg/syscall/mkall.sh (right):
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/mkall.sh#ne...
src/pkg/syscall/mkall.sh:160: mksysnum="./mksysnum_plan9.sh
/media/sys/src/libc/9syscall/sys.h"
On 2011/02/09 19:50:19, ality wrote:
> Maybe change this to point to sources so others
> know where to find it? /n/sources/plan9/...
>
> Not terribly important, though.
Done.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/syscall_pla...
File src/pkg/syscall/syscall_plan9.go (right):
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/syscall_pla...
src/pkg/syscall/syscall_plan9.go:109: func atoi(buf []byte) int {
On 2011/02/09 19:50:19, ality wrote:
> These two functions could be shorter if
> you used named result parameters. E.g.,
>
> func atoi(b []byte) (n int) {
> for i := 0; i < len(b); i++ {
> n = n*10 + int(b[i] - '0')
> }
> return n
> }
>
> func findnull(b []byte) (i int) {
> for ; i < len(b) && b[i] != '\0'; i++ {
> }
> return i
> }
Done.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/syscall_pla...
src/pkg/syscall/syscall_plan9.go:233: return sleep(int32((nsec + 999) / 1e6))
On 2011/02/09 19:50:19, ality wrote:
> Add the comment "round up to milliseconds"
> to match the other syscall_$arch.go files.
Done.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/syscall_pla...
src/pkg/syscall/syscall_plan9.go:267: func Await(msg *Waitmsg) (err Error) {
On 2011/02/09 19:50:19, ality wrote:
> You can avoid the append here by doing
> something like the following:
>
> func Await(w *Waitmsg) (err Error) {
> var buf [512]byte
> var f [5][]byte
>
> n, err := await(buf[:])
> if err != nil || w == nil {
> return
> }
>
> var nf, p int
> for i := 0; i < n && nf < len(f); i++ {
> if buf[i] == ' ' {
> f[nf] = buf[p:i]
> p = i+1
> nf++
> }
> }
> if nf != len(f) {
> return NewError("invalid wait message")
> }
> w.Pid = atoi(f[0])
> w.Time[0] = uint32(atoi(f[1]))
> w.Time[1] = uint32(atoi(f[2]))
> w.Time[2] = uint32(atoi(f[3]))
> w.Msg = string(f[4])
> return
> }
Done.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/syscall_pla...
src/pkg/syscall/syscall_plan9.go:340: fd, e := Open("#c/bintime", O_RDONLY)
On 2011/02/09 19:50:19, ality wrote:
> This should be "/dev/bintime". Someone may have
> bound in another file. Cinap has a pretty neat
> utility called warpfs (on contrib) that does this.
Done.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/syscall_pla...
src/pkg/syscall/syscall_plan9.go:346: _, e = Pread(fd, b[:], 0)
On 2011/02/09 19:50:19, ality wrote:
> Why not check that you've read at least 8 bytes?
Done.
http://codereview.appspot.com/3816043/diff/125001/src/pkg/syscall/syscall_pla...
src/pkg/syscall/syscall_plan9.go:367: err_buffer := make([]byte, ERRMAX)
On 2011/02/09 19:50:19, ality wrote:
> Any reason this can't be "var buf [ERRMAX]byte"?
Done.
Thanks for the review! http://codereview.appspot.com/3816043/diff/133002/src/pkg/syscall/asm_plan9_386.s File src/pkg/syscall/asm_plan9_386.s (right): http://codereview.appspot.com/3816043/diff/133002/src/pkg/syscall/asm_plan9_386.s#newcode162 src/pkg/syscall/asm_plan9_386.s:162: TEXT ·seek(SB),7,$0 On 2011/02/11 19:31:35, ...
14 years, 1 month ago
(2011-02-12 15:59:38 UTC)
#16
still absorbing it http://codereview.appspot.com/3816043/diff/138016/src/pkg/syscall/asm_plan9_386.s File src/pkg/syscall/asm_plan9_386.s (right): http://codereview.appspot.com/3816043/diff/138016/src/pkg/syscall/asm_plan9_386.s#newcode125 src/pkg/syscall/asm_plan9_386.s:125: CALL runtime·entersyscall(SB) rsc may disagree but ...
coming along nicely http://codereview.appspot.com/3816043/diff/135042/src/pkg/syscall/exec_plan9.go File src/pkg/syscall/exec_plan9.go (right): http://codereview.appspot.com/3816043/diff/135042/src/pkg/syscall/exec_plan9.go#newcode120 src/pkg/syscall/exec_plan9.go:120: // Return a list of currently ...
Thanks! http://codereview.appspot.com/3816043/diff/135042/src/pkg/syscall/exec_plan9.go File src/pkg/syscall/exec_plan9.go (right): http://codereview.appspot.com/3816043/diff/135042/src/pkg/syscall/exec_plan9.go#newcode120 src/pkg/syscall/exec_plan9.go:120: // Return a list of currently opened fd's ...
i think this is looking good. someone else should take a look. http://codereview.appspot.com/3816043/diff/143016/src/pkg/syscall/syscall_plan9.go File src/pkg/syscall/syscall_plan9.go ...
On Feb 22, 2011, at 2:06 PM, paulzhol@gmail.com wrote:
>
http://codereview.appspot.com/3816043/diff/135042/src/pkg/syscall/mksysnum_pl...
> src/pkg/syscall/mksysnum_plan9.sh:19: cat $1 | sed -r 's/^#define[
> \t]([A-Z0-9_]+)[ \t]+([0-9]+)/\tSYS_\1=\2/g' | grep -v SYS__
> On 2011/02/22 18:35:16, r wrote:
>> this could be
>> < $1 sed....
>> but you can leave it as is if you prefer
>
> Is it "better" because cat is not opening a new file descriptor, letting
> the shell do that for it instead ?
why start a process when you can just open a file?
-rob
sorry for the delay. these are mostly cosmetic. it's close to ready. http://codereview.appspot.com/3816043/diff/176002/src/pkg/syscall/exec_plan9.go File src/pkg/syscall/exec_plan9.go ...
13 years, 11 months ago
(2011-03-31 22:51:24 UTC)
#28
On 2011/04/02 19:39:37, r2 wrote: > looks like you've updated, but i didn't get a ...
13 years, 11 months ago
(2011-04-02 19:44:08 UTC)
#33
On 2011/04/02 19:39:37, r2 wrote:
> looks like you've updated, but i didn't get a PTAL mail. is it ready for
review?
>
> -rob
>
Yes it is ready, sorry. I thought Russ needs to OK it first.
On 2011/04/02 19:54:53, r wrote: > one small portability issue > > http://codereview.appspot.com/3816043/diff/199001/src/pkg/syscall/mksysnum_plan9.sh > File ...
13 years, 11 months ago
(2011-04-02 20:42:05 UTC)
#35
Issue 3816043: code review 3816043: syscall: Plan 9 support for x86.
(Closed)
Created 14 years, 2 months ago by paulzhol
Modified 13 years, 11 months ago
Reviewers:
Base URL:
Comments: 141