I think it was Erick which asked about renaming Tvx-root to tvxroot.
Before I ask upstream I want to make sure that I get things sorted out with
the naming.
I see renaming Tvx to tvx, and Tvx-root to tvxroot. What is the
preference with the docs and the source. tvxrootsrc seems a bit unwieldy,
> never attribute to funny hardware that
> which can be adequately explained by
> broken locking.
>
> - erik
That's a nice quotable quote ;-)
> The stack protector code came in to some distros (e.g. ubuntu) and it
> causes major trouble (for coreboot among other things) if you do
> things slightly out of the standard. You need -fno-stack-protector I
> would assume with vx32.
yes, it was for building vx32 as I recall. Thanks for the p
On Sat, May 29, 2010 at 4:05 AM, EBo wrote:
> gcc -fno-inline -c -g -O3 -MD -std=gnu99 -O2 -march=i486 -pipe
>
> and
>
> gcc -m32 -c -nostdinc --g -O3 -MD -std=gnu99 -O2 -march=i486 -pipe
> -fno-stack-protector -m80387 -mfp-ret-in-387
The stack protector code came in to some distros (e.g. ubun
On Sat, May 29, 2010 at 4:09 AM, erik quanstrom wrote:
> why were the flags set to -O3?
I have no idea, I did not set this up. Sometimes, for some of the
weirder tricks the GNU/Linux guys play, you have to have at least -O2
... inb/outb macros being one example.
ron
On Fri May 28 23:41:33 EDT 2010, rminn...@gmail.com wrote:
> OK, somebody sent a hint that it might make sense to take the -O3 out
> of the make flags. Done.
why were the flags set to -O3?
- erik
On Sat, 29 May 2010 03:39:46 +, ron minnich
wrote:
> OK, somebody sent a hint that it might make sense to take the -O3 out
> of the make flags. Done.
>
> Result: I can now get through this command:
> hget -v
> http://plan9.bell-labs.com/plan9/download/plan9.iso.bz2>/tmp/iso.bz2
> |[2]aux/stat
OK, somebody sent a hint that it might make sense to take the -O3 out
of the make flags. Done.
Result: I can now get through this command:
hget -v http://plan9.bell-labs.com/plan9/download/plan9.iso.bz2>/tmp/iso.bz2
|[2]aux/statusbar plan9.iso
without an explosion.
We'll see. I'm always ready to
Hi all,
I picked up an Intel Desktop Board D410PT today with the intention of
using it
to run 9atom but I am finding that it panics on boot regardless of any
switches
I might set in the BIOS:
PBS1...Plan 9 from Bell Labs
ELCR: 0E00
pcirouting: South bridge 8086, 27BC not found
cpu0: 1668 M
> Wow. That's a level of quality and fulfillment I did not believe
> possible. 32-bit or 64-bit?
>
> gcc -v -v says what?
>
> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
>
> for me.
>
> Could it be because your laptop is 220V?
never attribute to funny hardware that
which can be adequately explai
On Fri, May 28, 2010 at 11:36 AM, Charles Forsyth wrote:
>>If you run it -g, what happens?
>
> init: starting /bin/rc
> 1416: signal: sys: segmentation violation
>
>
Wow. That's a level of quality and fulfillment I did not believe
possible. 32-bit or 64-bit?
gcc -v -v says what?
gcc version 4.4
FYI, I found that in src/9vx/main.c, in main(), setmach(&mach0) is
called before mach0init() and thus machkeyinit() ... if you move
machkeyinit() from mach0init() to main(), before setmach(&mach0) ... do
you still have a crash ?
BTW, it does not fix the lotsafiles bug ...
Phil;
Charles Forsy
>If you run it -g, what happens?
init: starting /bin/rc
1416: signal: sys: segmentation violation
On 28 May 2010, at 17:04, Bakul Shah wrote:
On Fri, 28 May 2010 12:51:36 BST Ethan Grammatikidis > wrote:
On 27 May 2010, at 21:16, Bakul Shah wrote:
If BSD had
implemented ".." correctly (i.e. walk back up one level in
the given path), symlinks would have been more useful and
less surprisi
On 28 May 2010, at 17:26, erik quanstrom wrote:
are ls, grep, and diff.
bsd: never an option too arcane to refuse.
s/bsd/bsd|gnu/
Actually freebsd uses gnu grep and both get diff from the diffutils
package.
--
Simplicity does not precede complexity, but follows it. -- Alan Perlis
> are ls, grep, and diff.
bsd: never an option too arcane to refuse.
- erik
On 28 May 2010, at 16:09, Steve Simon wrote:
almost no unix programs (other than find)
bother with mount points.
Ok, only because it was in my final year exams, I know of one more
pwd needs to understand mount points (or did in v7) so it can step
over them - no doubt ther is a getwd() system
> The kernel needs to keep the full path to $PWD in order to
> perform this simplification with relative paths. In effect
> the kernel needs to strip out all .. from a given path before
> interpreting it. And of course the kernel must check that
> names an existent directory.
cf. /sys/src/9/por
On Fri, 28 May 2010 12:51:36 BST Ethan Grammatikidis
wrote:
>
> On 27 May 2010, at 21:16, Bakul Shah wrote:
>
> > If BSD had
> > implemented ".." correctly (i.e. walk back up one level in
> > the given path), symlinks would have been more useful and
> > less surprising.
>
> This "correct" imp
you folks who are crashing 9vx in startup.
If you run it -g, what happens?
ron
centos 5.4 x64 with your 9vx.
ron minnich wrote:
On Fri, May 28, 2010 at 6:40 AM, Philippe Anel wrote:
Could not crash with your program, but it crashed quite fast with this one:
and mine did not crash at all with that one. What system were you on?
ron
On Fri, May 28, 2010 at 6:40 AM, Philippe Anel wrote:
> Could not crash with your program, but it crashed quite fast with this one:
and mine did not crash at all with that one. What system were you on?
ron
> almost no unix programs (other than find)
> bother with mount points.
Ok, only because it was in my final year exams, I know of one more
pwd needs to understand mount points (or did in v7) so it can step
over them - no doubt ther is a getwd() system call these days,
darn'ed new fangled things.
> > would you deconstruct bind/mount points as well?
> > recursively? that way lies vms/windows.
>
> No, a bind's different... Maybe I'm being an idiot, but I'd like to
> have a neat & tidy argument against symlinks, saying symlinks
> introduce a "damned if you do, damned if you don't" kind of
On 28 May 2010, at 12:59, erik quanstrom wrote:
On 27 May 2010, at 21:16, Bakul Shah wrote:
If BSD had
implemented ".." correctly (i.e. walk back up one level in
the given path), symlinks would have been more useful and
less surprising.
This "correct" implementation of symlinks has never se
> On 27 May 2010, at 21:16, Bakul Shah wrote:
>
> > If BSD had
> > implemented ".." correctly (i.e. walk back up one level in
> > the given path), symlinks would have been more useful and
> > less surprising.
>
> This "correct" implementation of symlinks has never seemed right to
> me. Linux /
On 27 May 2010, at 21:16, Bakul Shah wrote:
If BSD had
implemented ".." correctly (i.e. walk back up one level in
the given path), symlinks would have been more useful and
less surprising.
This "correct" implementation of symlinks has never seemed right to
me. Linux / Bash used to do it the
On 28 May 2010, at 11:34, erik quanstrom wrote:
Anyway, what really stuck in my mind from Korn's post was his
characterization of symbolic links as a "non local goto", and I got
the impression from the "paper" that he was not enthusiastic about
the
idea in general, much less the implementati
> Anyway, what really stuck in my mind from Korn's post was his
> characterization of symbolic links as a "non local goto", and I got
> the impression from the "paper" that he was not enthusiastic about the
> idea in general, much less the implementations.
and, the whole idea breaks down unless th
>
> Maybe it's as simple as a buffer overflow in devfs-posix.c?
>
that's trivial to test. try lotsafiles with ramfs.
- erik
Sorry, I was talking about 9vx/main.c:^main of course.
But forget it, it still crashes ... it just takes more time before crashing.
I suspected the fork in main() because I do not have (for a very very
long time) crash with '-F' flag (ie nofork).
Phil;
Philippe Anel wrote:
I rewrote a simple
I rewrote a simple version with fork(). And got a crash until I move :
#ifndef __APPLE__
if(!usetty && !nofork && fork() > 0)
_exit(0);
#endif
before mach0init();
Now it no longer crashes.
Phil;
32 matches
Mail list logo
