On Wed, Jul 2, 2008 at 8:35 PM, erik quanstrom [EMAIL PROTECTED] wrote:
Also, public 9grids. Though judging by gdiaz's experiences with
sirviente, there's a bit of work to be done in that area - I get the
impression things are fairly unstable once the machine gets under
memory pressure.
sqweek wrote:
On Wed, Jul 2, 2008 at 8:35 PM, erik quanstrom [EMAIL PROTECTED] wrote:
Also, public 9grids. Though judging by gdiaz's experiences with
sirviente, there's a bit of work to be done in that area - I get the
impression things are fairly unstable once the machine gets under
memory
Swap doesnt work reliable here. :-(
I have disabled swaping and let the kernel kill the biggest process
skipping any critical server processes and it works well.
got ~100 days uptime and i use this machine for linuxemu
development/testing.
i'm curious as to what is taking so much memory.
-
the alternative is to add very
large amounts of code to the kernel.
not really. the alternative is to add some code to the
kernel, and varying amounts of code to quite a few applications.
no adding very large amounts of code... maybe fix the swap... or even
remove it alltogether.
assuming it doesn't work now, the paging code used to work, at least
in the sense of survive --i used 8l to link kernels on a 4mbyte 386sx16 --
so i imagine it's just a matter of repairing it, if it
On Tue, Jul 22, 2008 at 11:50 PM, Charles Forsyth [EMAIL PROTECTED] wrote:
no adding very large amounts of code... maybe fix the swap... or even
remove it alltogether.
assuming it doesn't work now, the paging code used to work, at least
in the sense of survive --i used 8l to link kernels on a
The kernel mkfiles don't know how to build dependencies from
the cmd tree. The mk you're doing knows fossil is missing or out
of date, but not how to do anything about it. Build it yourself. I
mk all of /sys/src/cmd to be safe, but you could just hit the list
you need for your kernel (whatever
Thank you both for your infromative replies.
A 'mk all' in /sys/src/cmd gave errors so I am doing a pull now
Bob
erik quanstrom wrote:
I am having trouble building a new kernel for a terminal.
I do
mk 'CONF=pcf'
and I get the error
mk: don't know how to make '/386/bin/fossil/fossil' in directory
/sys/src/9/pc
does /386/bin/fossil/fossil exist? if not, it's a little
worrying that it
Ok. I pulled and remade fossil which got over that error. But now I do
mk 'CONF=pcf' and get
size 9pcf
links: incompatible type signitures ..(for a whole load of init
files ie tcpinit, udpinit etc)
and then
mk: 8c -FTVv '-DKERNDATE='`{date ... : exit status=rc 1887: 8l 1891
this would be expected due to the pull which sets the mtimes of
new files to be older than the .8s. try mk clean before proceeding.
i should explain that type signatures are 32-bit
signatures in .$O files that define the type of
external symbols. the c compiler sets the type
signature to zero
it will work perfectly if the -T flag is not
given (since there is a deep assumption
in plan 9 that int == long). but i the
not exactly. it will work on most Unix systems and
on Plan 9 without -T because nothing checks
external types across object module boundaries. the linker/loader in both
not exactly. it will work on most Unix systems and
on Plan 9 without -T because nothing checks
external types across object module boundaries. the linker/loader in both
systems
will allocate in BSS the largest size seen for a given symbol,
so it doesn't matter whether int == long or not.
erik quanstrom wrote:
Ok. I pulled and remade fossil which got over that error. But now I do
mk 'CONF=pcf' and get
size 9pcf
links: incompatible type signitures ..(for a whole load of init
files ie tcpinit, udpinit etc)
and then
mk: 8c -FTVv '-DKERNDATE='`{date ... : exit status=rc
There have been several discussions on this list about 9vx's
IP stack being different from normal Plan 9 in the last two
weeks; you should check those out. The short version is that
9vx uses the host networking rather than its own, and (more-
or-less) consequently the kernel device presents a more
not exactly. it will work on most Unix systems and
on Plan 9 without -T because nothing checks
external types across object module boundaries. the linker/loader in both
systems
will allocate in BSS the largest size seen for a given symbol,
so it doesn't matter whether int == long or not.
Hi!
I'am new to 9vx/p9p and try to configure /net.
# uname -a
FreeBSD r60e 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Wed Jul 9 17:33:56 UTC 2008
gonzo@:/usr/obj/usr/src/sys/GENERIC i386
% bind -b '#I' /net
% ip/ipconfig -g 192.168.0.1 ether /net/ether0 192.168.0.32 255.255.255.0
ipconfig: no
9,
mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip
does /sys/src/cmd/ip/pptpd.c exist? if not, there must be an
error in the pull database on sources. you can copy it
by hand with
9fs sources cp -x /n/sources/plan9/sys/src/cmd/ip/pptpd.c
/sys/src/cmd/ip/
Erik, it
Erik, it already exists and has the same MD5 checksum than the one in
sources.
i'm fresh out of ideas, then.
what i know is
a) it build just fine on my system, but i don't use pull.
b) if for some xyzw mk requires xyzw.8 and there's no xyzw.$x
so that there's a mk rule like so %.8: %.$x, i get
9,
mk: no recipe to make 'pptpd.8' in directory /sys/src/cmd/ip
does /sys/src/cmd/ip/pptpd.c exist? if not, there must be an
error in the pull database on sources. you can copy it
by hand with
9fs sources cp -x /n/sources/plan9/sys/src/cmd/ip/pptpd.c
/sys/src/cmd/ip/
Erik, it
As far as I could find, there isn't a newer version of sam for Windows then the
one from 9pm, so I started trying to port the plan9port version. So far, I got
all of the stuff in the sam/ directory to compile.
I'm stuck on lib9, though, since it doesn't compile on Windows in its current
form.
Benjamin Huntsman wrote:
might it be more straightforward to modify the plan9port sam to run on 9pm, or
would the only way to get it running on Windows be to port the whole lib9 from
p9p at the same time?
... I hate Windows, but alas, it's what I have to live with for my job ..
Here is a
could p9p possibly compile and run under Cygwin?
Might be an easier port... MinGW might be preferable, as drawterm uses it, and
again might be easier...
Neither would work out of the box, though.
An extra of indirection may not be the most efficient thing, but...
My approach thus far has been
dt can be compiled using either mingw or ms tools. might want to read
rsc's recent post about 9vx port to windows and the relative ease
compared to porting p9p.
could p9p possibly compile and run under Cygwin?
Might be an easier port... MinGW might be preferable, as drawterm uses it,
and
I have a long term project to get somthing like p9p running under windows
though my goal is to use a windows box as a plan9 cpu server so /dev/draw
is not a priority.
My approach is very similar to Russ's p9p for windows alpha on swtch.com
but it is many months away from finished - i get a day a
what i know is
a) it build just fine on my system, but i don't use pull.
b) if for some xyzw mk requires xyzw.8 and there's no xyzw.$x
so that there's a mk rule like so %.8: %.$x, i get the following
error message
; mk xyzw.8
mk: no recipe to make 'xyzw.8' in directory
Bob,
mk: don't know how to make '/386/bin/fossil/fossil' in directory
/sys/src/9/pc
touch /386/bin/fossil/fossil then you can mk 'CONF=pcf' if you want.
Hope this helps,
Jerome Ibanes
touch /386/bin/fossil/fossil then you can mk 'CONF=pcf' if you want.
if you are trying to boot from a fossil root and do this,
your kernel will not be able to successfully mount the root
filesystem.
don't do this if you expect to boot.
Only if there was no /386/bin/fossil/fossil before.
28 matches
Mail list logo
