just a reminder, when I build from sysfromiso, on 9vx:
cd sysfromiso
hg pull
hg up
bind sys/src /sys/src
bind sys/include /sys/include
cd /sys/src
objtype=arm
mk nuke
mk install
I've used this to build bootable openrd kernels. I'm rerunning it now.
It always takes time because of gs, but gs is a
Build went fine.
On Sun, Dec 5, 2010 at 10:15 AM, ron minnich wrote:
> just a reminder, when I build from sysfromiso, on 9vx:
>
> cd sysfromiso
> hg pull
> hg up
> bind sys/src /sys/src
> bind sys/include /sys/include
> cd /sys/src
> objtype=arm
> mk nuke
> mk in
On Mon, Dec 6, 2010 at 5:08 PM, Paul Lalonde wrote:
> I got it clean, finally. I had mis-mapped some pieces while updating my x86
> userland, without which 5c crapped out a lot.
> Next question: How do I build my plug kernel? Among my early build
> problems:
> mk: no recipe to make 'devtwsi.
On Mon, Dec 6, 2010 at 5:54 PM, erik quanstrom wrote:
> On Mon Dec 6 20:14:54 EST 2010, rminn...@gmail.com wrote:
>> On Mon, Dec 6, 2010 at 5:08 PM, Paul Lalonde
>> wrote:
>> > I got it clean, finally. I had mis-mapped some pieces while updating my
>> > x86
>> > userland, without which 5c cra
On Tue, Dec 7, 2010 at 5:37 AM, erik quanstrom wrote:
> there is no current version in pc. this is what you're intersted in
> ./port/syscallfmt.c
> ./kw/syscall.c
Those are in now as well.
ron
On Tue, Dec 7, 2010 at 8:26 AM, ron minnich wrote:
> On Tue, Dec 7, 2010 at 5:37 AM, erik quanstrom wrote:
>
>> there is no current version in pc. this is what you're intersted in
>> ./port/syscallfmt.c
>> ./kw/syscall.c
>
> Those are in now as well.
or wil
On Tue, Dec 7, 2010 at 8:26 PM, Paul Lalonde wrote:
> I have a successful boot off my USB stick onto the Guru.
> Now, how do I tell it to use the USB stick as a root filesystem? I'm
> guessing I'll want to have two partitions, one to hold the image and another
> as a native P4 fs of some sort (if
On Tue, Dec 7, 2010 at 10:13 PM, Lucio De Re wrote:
> On Tue, Dec 07, 2010 at 09:25:37PM -0800, ron minnich wrote:
>>
>> I've gotten part of the way there. I set up a 9fat on the first
>> partition and I can boot the kernel from u-boot with the 9fat. But I'm
>&
I just noticed this one:
http://www.gumstix.com/store/catalog/product_info.php?products_id=244
there's even a $45 one. I may get one and see. Terminals keep getting cheaper.
ron
On Thu, Dec 9, 2010 at 9:22 AM, erik quanstrom wrote:
> On Thu Dec 9 12:17:28 EST 2010, 23h...@googlemail.com wrote:
>> Erik, if I want "fast" I know where to look.
>
> i believe the op's original adjective cheep. not fast.
another part of my objective is open down to the metal. PCs just are
no
On Fri, Dec 10, 2010 at 7:42 AM, John Floren wrote:
> My problem was always forgetting to uncomment the keyfs line in cpurc.
> I'd be able to log in as bootes but nothing else.
Maybe the single most important document would be a set of key-value pairs:
"I have this problem"
"Then you need to thi
I am having a simple problem which I know I've already solved -- but
the machine is elsewhere.
I am building a plug kernel. I've made the following change to plug
config file:
bootdir
boot.fs boot
/arm/bin/rc
/rc/lib/rcmain
The boot.fs just has this:
#!/boot/rc -m /boot
On Sun, Dec 12, 2010 at 4:37 PM, ron minnich wrote:
> I am having a simple problem which I know I've already solved -- but
> the machine is elsewhere.
It's turning out not to be simple at all. The *init* is the init
process. It is the hand-crafted kernel process and it sets up
can't write papers without bibtex.
reviewers get angry if you don't cite their papers in your
submission,and will happily bounce your paper for that reason alone.
ron
Sorry, I'm tired, long day, but this discussion is not making sense to
me. I hope I don't make anyone mad at me :-)
9vx can accept connections today, with or without the ether device.
I've used 9vx to export root file systems to ARMs. It's how I
bootstrapped my openrd.
Now, there is this business
The ssh option works fine for me.
There is one well-known issue with ssh and one with python. But there
is a group of us who have been using bitbucket for several years now
and it can work.
ron
On Fri, Dec 31, 2010 at 5:36 PM, Fernan Bolando wrote:
> rminnich/sysiso ??
>
sysfromiso -- the intent of this is to provide an hg tree that is an
exact copy of /sys/src and inlcude, so you can build a full / from it.
It's interesting to watch the continuing improvements Geoff and others
pu
On Mon, Jan 3, 2011 at 8:11 AM, Fernan Bolando wrote:
> hi all
>
> can anyone else confirm that the attached file effectively kills 8c?
> it dies on 9vx and virtualbox, will test it on real hardware tomorrow.
>
> cpp -D__STDC__=1 -N -I. -D_PLAN9 -D_POSIX_SOURCE -D_BSD_EXTENSION
> -D_C99_SNPRINTF_E
On Sat, Jan 8, 2011 at 6:24 PM, Lyndon Nerenberg (VE6BBM/VE7TFX)
wrote:
>> thinking about it... why not just let stream() fail and let the program
>> decide if it makes sense to continue without it?
>
> Exactly what I was thinking. If the program requires the semantics of
> stream(), it should be
simple question: what's it take to set up a kenfs + coraid combo? Or
is there a howto somewhere on your site? I'd like to give this a go.
Those are interesting numbers. Actually, however, changing a program
to use the stream stuff is trivial. I would expect the streaming to be
a real loser in a si
On Sun, Jan 9, 2011 at 11:54 AM, Bakul Shah wrote:
>None of these
> use any streaming (though there *is* readahead at the FS
> level).
yes, all the systems that perform well do so via aggressive readahead
-- which, from one point of view, is one way of creating a stream from
a discrete set of req
On Sun, Jan 9, 2011 at 12:47 PM, erik quanstrom wrote:
> however, i think we could do even better by modifying devmnt
> to keep more than 1 outstanding message per channel, as a mount
> option. each 9p connection can stream without the overhead of
> seperate connections.
>
> this is the stragegy
On Sun, Jan 9, 2011 at 1:38 PM, Bakul Shah wrote:
> I didn't say plan9 "suffers". Merely that one has to look at
> other aspects as well (implying putting in Tstream may not
> make a huge difference).
well, what we do know from one set of measurements is that it makes a
measurable difference whe
On Sun, Jan 9, 2011 at 2:58 PM, Charles Forsyth wrote:
> it's curious that people are still worrying about "local" file systems
> when so much of most people's data increasingly is miles
> away on Google, S3, S3 via Drop Box, etc, which model is closer if anything
> to the
> original plan 9 model
can you do a ratrace for me?
ron
On Tue, Jan 11, 2011 at 9:03 AM, Charles Forsyth wrote:
> i suspect go is using segment register(s) to implement extern register,
> and that isn't expected (or perhaps even supported) by 9vx.
> just a guess.
>
>
I did not realize this was currently supported by Plan 9 ... maybe I
didn't get the m
On Tue, Jan 11, 2011 at 10:55 AM, Anthony Martin wrote:
> Pavel Zholkover once said:
>> I'm typing from my phone so I don't have go sources in front of me,
>> but 0xdfffefc0 looks like the address I used for per thread G and M
>> structs - just bellow struct Tos.
>>
>> Andrey and I also tried run
On Wed, Jan 12, 2011 at 9:12 AM, andrey mirtchovski
wrote:
> slightly different on my mac, so i'll post it:
>
> 61: page fault 0x10bc MOVL CX,0xdfffefc0
eek. Yeah, I guess the guys are right, you're dying on access to stack?
which 9vx are you running? I'm on travel but will look at this tom
On Wed, Jan 12, 2011 at 12:32 AM, Skip Tavakkolian
wrote:
> On Tue, Jan 11, 2011 at 8:25 AM, ron minnich wrote:
>> can you do a ratrace for me?
>>
>> ron
>>
>>
>
> i'll have to rebuild using the vx32 branch on your bitbucket. is it up
> to date wit
On Sat, Jan 15, 2011 at 1:42 AM, Akshat Kumar
wrote:
> I have this exact thing. Direct from China.
>
> It has a terribly slow interface, heats up
> during calls, and runs out of battery during
> actual call times, like no other.
>
> It's good if all you care about is the "smart"
> part of "smart p
Just FYI, I wanted to verify that this works and I just did.
Having a 9vx function as the fs for an Ovaro (TI OMAP)
sudo ~/src/plan9/vx32/src/9vx/9vx -r ~/src/9vx-0.12/
The sudo is important.
Then in the 9vx instance:
aux/listen1 -v tcp!*!564 /bin/exportfs -s
Then I boot the Ovaro:
Filena
On Sun, Jan 16, 2011 at 7:43 AM, hiro <23h...@googlemail.com> wrote:
> You mean an Overo?
yea, sorry, I keep misspelling it.
> Is there any place where I can watch the ARM port
> status for all these different devices?
sources :-)
ron
On Sun, Jan 16, 2011 at 11:41 AM, erik quanstrom wrote:
> i haven't cracked the case. does anyone know if there's
> a jtag port at all in a sheevaplug?
Another possibility -- the omap "on chip" firmware will use SD-based
uboot image if it finds it, instead of flash. If the plug plays by the
sam
On Mon, Jan 17, 2011 at 9:00 AM, Skip Tavakkolian
wrote:
> 9vx (built from Ron's bitbucket) complains with the following, but no
> ill effect that i can see -- it continues to run.
>
> cpu2 deadlock? 91e9c0 caller=7f5b8ef12ec8
> cpu2 deadlock? 91e9c0 caller=7f5b8ef12ec8
>
>
I see them too on all
Pavel built a reproducer and sent it to me:
-- Forwarded message --
From: Pavel Zholkover
Date: Mon, Jan 17, 2011 at 12:24 PM
Subject: Re: plan9 go output faults on 9vx with rfork
To: ron minnich
Hi Ron!
I think I've traced the cause of the crash. It is unfortunatel
OK, Pavel sent me a nice piece of code that implements cmpswap using a
gcc trick. I did not want to use the trick for a few reasons, and
thought to use futex instead, as it seemed appropriate. Weirdly
enough, I can not find a simple implementation of cmpswap that uses
futex, though I can find sever
On Thu, Jan 20, 2011 at 1:44 PM, David Leimbach wrote:
> yeah it's so easy to make screenshots :-)
but then you have to pick up all the glass shards. That's harder.
ron
This started to look like a 32/64 problem and I think it is. If you
trace the cmpswap, at some point we see 1 as a value, just
like somebody added 1 to , and it went to, not 0, as expected,
but a bigger value.
See this code:
long
syssemacquire(uint32 *arg)
{
int block;
On Sat, Jan 22, 2011 at 6:48 PM, erik quanstrom wrote:
> the plan 9 core needs to religiously use uintptr and not long. long
> is always wrong for these things.
It's a bit messier than that. When 9vx is built as 64-bit, it's a
64-bit kernel supporting 32-bit binaries. uintptr is still a 64-bit
On Sun, Jan 23, 2011 at 12:40 PM, EBo wrote:
>>> in the plan 9 world, a 64-bit kernel runs 64-bit applications,
>>> and 32-bit applications run on a 32-bit kernel.
>>
>> It would, but vx32 still just "emulates" an i386. So even if 9vx is
>> built to run on amd64, the underlying Plan 9 environment
On Sun, Jan 23, 2011 at 3:40 PM, Charles Forsyth wrote:
>> So, what changes are needed to set it up for full 64bit?
>
> i'm confused. why would you bother if you can only run 32-bit x86 code in
> vx32?
I'm not sure either, unless there is some feeling that it runs better
as a 64-bit binary.
ron
apropos this discussion, I just "fixed" (maybe in the veterinary
sense?) my vx32 repo to only build 32-bit, regardless of what machine
one is on.
Tested on linux/32 and linux/64 and darwin
ron
On Mon, Jan 24, 2011 at 9:18 AM, yy wrote:
> 2011/1/23 ron minnich :
>> change all sem* bits in a/sysproc.c to use uint32 not long
>> change ed script so it won't do the wrong thing in future.
>
> Just for the records, the ed scripts are not working with current
> ke
On Mon, Jan 31, 2011 at 10:02 PM, wrote:
> term% mkdir trashdir && cd trashdir && mkdir x
> term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
> i=`{echo $i+1|hoc} } }
> term% cp abc* abc* x
> # watch the cp executable suicide
> # now, make SURE there's nothing in this rio w
On Sat, Jan 29, 2011 at 2:47 PM, wrote:
> I'm REALLY hoping someone can help me with this...
>
>
BTW, apropos this sad tale, go ahead and install python and mercurial
on your plan 9 system. Then set up a repo on a free place like
bitbucket. Voila, standard tools, which make Plan 9 a better place
On Tue, Feb 1, 2011 at 6:49 AM, erik quanstrom wrote:
>> least for me). Then I don't have to worry about whether I screwed up a
>> file system setup: that's what distributed repos are for.
>
> hg isn't a filesystem.
hg is not a lot of things. It is one thing, however, and the thing it
is is extre
On Tue, Feb 1, 2011 at 8:45 AM, erik quanstrom wrote:
>> Is fossil not a file system if it doesn't maintain a disk cache
>> and only dumps to venti? Perhaps our disagreement would be
>> solved by saying that its not a disk file system. Don't you
>> oppress me we with narrow minded views of what
On Tue, Feb 1, 2011 at 9:51 AM, wrote:
>However, the Plan 9 code (at last that under /sys/src/cmd)
> doesn't seem to make use of iterators, string objects (or even
> object-orientation), modern string parsing routines, etc.
There's a reason it does not use that stuff, and it may not be what you
On Tue, Feb 1, 2011 at 4:28 PM, wrote:
> ron minnich writes:
>
>> There's a reason it does not use that stuff, and it may not be what
>> you think.
>
> OK, come on already, quit teasing me! :) What's the secret reason?
I don't think it's a secre
Actually, I think we've talked quite enough at this point, perhaps
it's time to take a break and let's see some concrete work. Where's
the mkfile that broke your .h? What do your macros look like? What are
you going to do? I'll retire from the thread now.
Just remember, Smiley, it's a good idea no
On Wed, Feb 2, 2011 at 11:15 AM, wrote:
>> bugs, iterators and the other crap you mentioned would had obfuscated
>> it.
>
> The "other crap" I mentioned would have made that bug IMPOSSIBLE.
OK, let's do a test. You write your stuff with iterators and put it on
a machine with 256MB. I'll create
On Wed, Feb 2, 2011 at 4:52 PM, Charles Forsyth wrote:
> i suppose a more useful comment might be a question:
> how does a C compiler get to be that big? what is all that code doing?
iterators, string objects, and a full set of C macros that ensure
boundary conditions and improve interfaces.
ro
On Thu, Feb 3, 2011 at 12:49 PM, Federico G. Benavento
wrote:
> I don't know if f2c meets your needs, but it has always worked.
As compared to modern fortran compilers, it is basically a toy.
ron
On Sat, Feb 5, 2011 at 12:32 PM, Benjamin Huntsman
wrote:
>> Agreed, but is there a FORTRAN compiler/cross-compiler for Plan 9?
>
> I remember someone on here mentioning having a "translator" that could
> produce plan 9 executables from output from XLC or XLF as part of the Blue
> Gene stuff...
there's a race in ratrace: programs can escape. The reason is that the
parent forks a child and writes stop to its ctl file. But the child
can run any number of system calls -- even to completion -- before the
parent writes that stop command. I'm seeing this on arm.
The fix is simple, in the child
On Sun, Feb 13, 2011 at 7:50 PM, erik quanstrom wrote:
> at least from the source i have, writing to p->hang after
> the fork isn't going to do anything. p->hang is only consulted
> in sysexec. i think you need to add the same test in sysfork.
It is only supposed to be consulted in sysexec. Ha
On Mon, Feb 14, 2011 at 12:04 PM, Yaroslav wrote:
> is there some progress with creation of a Perfect Arm Terminal?
To me, the gumstix is still it. I booted the new omap kernel the other
day and noticed all the neat video messages! When I get back I'm going
to try it out with a display :-)
ron
On Wed, Feb 16, 2011 at 7:36 AM, Stanley Lieber
wrote:
> Reading old 9fans posts, I found Iru's modifications of vx32/9vx to run on
> OpenBSD 4.3.
> With this minor change:
>
> src/9vx/Makefrag:184: echo 'ulong kerndate ="' `date +%s` '";'
> >9vx/kerndate.h
>
> I was able to get it to buil
On Wed, Feb 16, 2011 at 8:42 AM, Stanley Lieber
wrote:
> Well, it builds, but it doesn't run.
>
> % ./9vx -r /n/plan9 -u glenda
> % 9vx panic: vxproc_run: Function not implemented
I feel we've been here before. Can you do an strace?
ron
It's been a long day and my debugging skills are lukewarm ...
can you run it with -g -S and see if we get any more useful output?
ron
hey is this 64 or 32 bit system?
uname -a?
If you told me that already, sorry, I missed it.
ron
On Wed, Feb 16, 2011 at 10:33 AM, Jacob Todd wrote:
> There's yiyus' and rminnichs' verions on bitbucket, just search for 9vx
> there and you should find them. I think ron's is a fork of yiyus', I'm not
> completely sufe how much the differ.
ron is a fork of the original. yiyus forked me, accordi
I was looking at another fine example of modern programming from glibc
and just had to share it.
Where does the getpid happen? It's anyone's guess. This is just so
readable too ... I'm glad they want to such effort to optimize getpid.
ron
#ifndef NOT_IN_libc
static inline __attribute__((always_i
On Fri, Feb 18, 2011 at 9:32 AM, erik quanstrom wrote:
> wire speed is generally considered "good enough". ☺
depends on field of use. In my biz everyone hits wire speed, and the
question from there is: how much of the CPU are you eating to get that
wire speed.
It's a very tangled thicked.
ron
On Fri, Feb 18, 2011 at 12:10 PM, Bakul Shah wrote:
> Templates encourage inlining. There is at least one template
> libraries where the bulk of code is implemented in separate
> .cc files (using void* tricks), used by some embedded
> products. But IIRC the original STL from sgi was all in .h
> f
On Mon, Feb 21, 2011 at 5:45 PM, erik quanstrom wrote:
> ah yes, that clears it up
>
> 19.4.22
> APICID
> This register uniquely identifies an APIC in the system. This register
> is not used by
> OS'es anymore and is still implemented in hardware because of FUD.
>
> (I
let me ask the question again. I know what the difference between APIC
and ACPI means.
Why is it that they don't think anyone needs that register any more?
What are they suggesting people use instead?
ron
On Mon, Feb 21, 2011 at 5:45 PM, erik quanstrom wrote:
> ah yes, that clears it up
>
> 19.4.22
> APICID
> This register uniquely identifies an APIC in the system. This register
> is not used by
> OS'es anymore and is still implemented in hardware because of FUD.
So, m
wireless support: se lucho's note about his almost-done wifi driver.
That said, you might want wireless usb with the atheros chip (6000
series?) that does most of the wireless stack. Charles knows more.
webcam: is this a usb webcam? USB support is getting better.
low power -- is an atom mobo low
On Sat, Feb 26, 2011 at 4:38 PM, Skip Tavakkolian
wrote:
> if i pxeload a cpu and want to be able to use an nvram partition on a
> usb disk (i.e. nvram=/dev/sdXX/nvram - once it is partitioned &
> formated). it seems i also must change boot/boot.c to add the 'partfs
> && fdisk -p && prep -p' after
in coreboot we went with an emulator instead of dropping to 16-bit and
running the bios. We did run 16-bit code directory for a few years (I
wrote that bit), but it's just too dangerous to trust a vga bios. I
think if a BIOS has to support VGA bios with an emulator then an OS
should do the same. We
I used to work with David Mills, back long ago. He was one of the
original Internet Buzzards, a really great guy. One of the many things
he invented was NTP.
He would get pretty exercised about keep-alives. Felt that it was not
the business of TCP to make these kinds of decisions. I can't remember
you have to allow for self modifying code. Yes, it's in there.
Great, huh? I love BIOS software.
ron
/boot/fossil: labelUnpack: bad label: 0xcb 0xb2 0x3d22d532 0x8cacb517 0xfc0d00cb
/boot/fossil: fsOpen error
fsOpen: corrupted block label
fsys main open -c 3000: fsOpen: corrupted block label
well, I don't have good words for you :-(
I think the sequence of failures here -- log messages of write
I don't know guys, these sure look like disk errors to me ...
ron
On Fri, Mar 18, 2011 at 7:53 PM, erik quanstrom wrote:
> i don't really think this is the problem, since a dd on the whole
> disk worked.
If you have a bad bit of memory it can result in exactly these sorts
of problems. Seen on a T23 I used to have, esp. when it decided to get
too warm. There ar
Erik, sounds like you need a motor generator ... flames from outlets
... wow ... maybe some opto isolators with a 2 meter air gap too :-)
ron
I've got a rejected-by-usenix paper somewhere about writing a 9p
encryption fs which you could stack on anything that served 9p:
exportfs, fossil, tarfs, whatever. It essentially attached to a 9p
server, you set the key, it encrypted/decrypted the data as it wrote
to its server.
The neat thing abo
This one is extremely weird.
On Tue, Mar 29, 2011 at 2:00 AM, Mathieu Lonjaret
wrote:
> Hi all,
>
> this is probably trivial; this is what I get when trying to start 9vx:
>
> Warning! factotum can't protect itself from debugging: '#p/5' file does not
> exist
> init: warning: can't open #p/2/ctl:
On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret
wrote:
> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
> patch, I think that means Yiyus' doesn't have it either. And yet,
> Yiyus' works for me, so I doubt this bug was the culprit for me. More
> like a 64 bits issue as Yi
My bet here is that if you build yiyus or ron tree and force 32-bit,
it will fail on a 64-bit system, no idea why. if you build with 64-bit
on yiyus tree, it will work.
In other words, I think the issue crops up on 32-bit 9vx on 64-bit
environments. At least that is how it seems to work.
I'm stil
On Tue, Mar 29, 2011 at 12:05 PM, erik quanstrom
wrote:
> On Tue Mar 29 12:48:21 EDT 2011, fors...@terzarima.net wrote:
>> in fact, even 64k might be too big a value for the given buf if it's near the
>> top of memory (eg, a local variable on a stack that's in high memory);
>> the PowerPC referenc
On Tue, Mar 29, 2011 at 1:25 PM, Charles Forsyth wrote:
>one question is: why does the 9vx environment
> make the original version of sprint fail?
I'm glad you asked that question :-)
I ran out of time to track it down. It's got something to do with how
the address space is set up in 32-bit 9vx
On Sat, Apr 2, 2011 at 4:52 PM, David Leimbach wrote:
> So wait... We can get the toolchain built on plan 9. Or we can target plan 9
> via cross compiler? Either way is pretty awesome! Nice work!
I'm trying a cross-build now
ron
On Sat, Apr 2, 2011 at 5:04 PM, ron minnich wrote:
> On Sat, Apr 2, 2011 at 4:52 PM, David Leimbach wrote:
>> So wait... We can get the toolchain built on plan 9. Or we can target plan 9
>> via cross compiler? Either way is pretty awesome! Nice work!
>
> I'm trying
Things went badly here:
8g -o _go_.8 exp.go normal.go rand.go rng.go zipf.go
gopack grc _obj/hash/crc32.a _go_.8
match.go:45: undefined: Separator
match.go:62: undefined: Separator
match.go:160: undefined: Separator
match.go:227: undefined: Separator
path.go:18: undefined: Separator
path.go:19: un
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 Pla
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,
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 say
well, Russ has blessed the runtime fix :-)
I look forward to having go in 9vx too!
ron
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
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
This discussion is interesting.
"rc is not as good a shell as bash because it lacks built-ins that
make it a good programming language for writing an acme extension"
Did I summarizer it correctly? Once summarized, am I the only one who
finds it absurd?
ron
On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox wrote:
> The best answer might be to make USTKTOP 1GB.
Agreed.
ron
On Tue, Apr 5, 2011 at 9:04 AM, Rudolf Sykora wrote:
> No. The discussion was not absurd.
> And no, Ron's summary was not a summary.
Well, I'm not so sure, because the original motivation was this: "I'm
trying to write an Acme client in rc(1). I'd like to avoid spawning
a new read(1) process e
On Tue, Apr 5, 2011 at 8:48 AM, ron minnich wrote:
> On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox wrote:
>
>> The best answer might be to make USTKTOP 1GB.
>
>
>
> Agreed.
My latest vx32 has the change and:
term% ./8.out
hello world
so Go is go on 9vx
ron
I regularly build kernels and full bins for arm on 9vx. the biggest
issue with osx is when you install 9vx on a case-insenstive file
system: things like /bin/Kill and /bin/kill don't quite work out.
ron
On Thu, Apr 7, 2011 at 8:45 AM, Paul Lalonde wrote:
> Fortunately you can build a case-insensitive file system on a mac, within a
> file. Disk Utility lets you make a filesystem in a file, and you can click
> "case-sensitive". Big win, and though you have to size the FS ahead, it's
> also nice t
On Thu, Apr 7, 2011 at 10:13 AM, Anthony Sorace wrote:
> On Apr 7, 2011, at 11:45, Paul Lalonde wrote:
>
>> Fortunately you can build a case-insensitive file system on a mac, within a
>> file.
>
> Just in case this wasn't obvious, you can do this with the real, on-disk
> filesystem, too. There's
Hi, it's me, the repeating person (I almost said "broken record" but
I'm not sure how many people know what that means any more :-)
Suggest you run your command with ratrace
ratrace - whatevercommandyouarerunning
It can be very revealing.
ron
901 - 1000 of 1311 matches
Mail list logo
