This one is extremely weird.
On Tue, Mar 29, 2011 at 2:00 AM, Mathieu Lonjaret
<mathieu.lonja...@gmail.com> 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: '#p/2' file does not exist
If #p does not work, well! things are seriously wrong. Do you ever get
an rc prompt?
Oh, I see; it's the ubuntu + sprintf problem. I should have taken
Christoph's patch, sorry about that; my fault.
As to your other questions. There's no real reason to build 9vx as a
64-bit binary, and it causes a lot of headaches, so I stick with a
32-bit version nowadays; also, I build all my binaries using my
sysfromiso repo as a starting point. In fact I build all my arm
kernels on 9vx using sysfromiso and use 9vx as the server for the root
file system for the ARMs. In spite of everything I much prefer hg to
replica.
We need a better way to keep 9vx going than just "Ron's version" or
"Joe's version" or whatever. Certainly patches should not just be
directed to me. I don't see the harm in bringing the discussions to
this list.
Here's the patch in question.
sprint(char *buf, char *fmt, ...)
{
int n;
- uint len;
va_list args;
- len = 1<<30; /* big number, but sprint is deprecated anyway */
- /*
- * on PowerPC, the stack is near the top of memory, so
- * we must be sure not to overflow a 32-bit pointer.
- */
- if(buf+len < buf)
- len = -(uintptr)buf-1;
-
va_start(args, fmt);
- n = vsnprint(buf, len, fmt, args);
+ n = vsnprint(buf, 65536, fmt, args);
va_end(args);
return n;
}
Note the len = 1 << 30; why was that ever done? I never figured that
out so was never sure about the implications of this patch. Anybody
know?
thanks
ron
