Re: Tor running on mipsel

["Ferdinand O. Tempel" <ftempel@xxxxxxxxxxxx>]

On Thu, 2004-12-23 at 16:15 -0500, Roger Dingledine wrote:
> Neat.
> 
> How much available ram do these things have while running? I worry that
> Tor's approach to buffers will cause it to constantly be hitting the
> ceiling. I would guess this is especially problematic for Tor servers.

Well, this particular model has 32MB of RAM available, from which part
is used for volatile stuff like /var and /tmp. I'm currently running
with ~11,8MB free memory and it's declining as I write this email. I
guess I need to monitor it for a while to see how it behaves. I *think*
I have tor running as a server now, but since I'm pretty new to this all
I still have to figure out stuff, like how to check on such details.

I do see the following error in syslog though:
Dec 23 22:34:50 10.164.10.1  Tor: connection_dir_client_reached_eof():
Received http status code 503 from dirserver. Failing.
Is that important?

If memory usage goes through the roof, I can always try to run tor in
client mode to see how that goes. Is there a way to limit tor's memory
usage, of would that require redesign of said buffer handling? By the
sound of it not a bad idea anyway.

> > It was a bit of a chore given the pretty, uhm, broken build process
> > which doesn't really support crosscompiling, but I managed it anyway.
> > Next up is privoxy.
> 
> If you have any suggestions to make our build process more pleasant
> for cross-compiling, we're very happy to take patches.

I'm no autotools expert, so I'll be glad to stay out of that :-)
I can however give you a hint on what I had to change:
The generated ./configure script does a check on the existance of
openssl by compiling a chunk of C. This check is surrounded by another
check on a variable "$cross_compiling", and is that variable is
set ./configure spits out a nice error about not being able to check for
openssl when crosscompiling. My solution was to edit configure.in so
that the bit which actually does the check never makes it into the
configure script. This is ugly of course, it would be better to
accompany --with-ssl-dir with something like --disable-ssl-check. If I
would know how, I'd provide a patch :-)

Second problem is that somewhere in the code there's a check for a
define, NULL_REP_IS_ZERO_BYTES. This too is checked by the configure
script, but it can't figure out the proper value by itself. My solution
is to explicitly #define it to 1 in orconfig.h.in. Another ugly
solution, but hey, that's my level of expertise I'm afraid :-)

All the rest is just setting paths to the right include files.

HTH.

-- 
Regards,

Ferdinand O. Tempel

Your friendly neighborhood linuxops.net administrator.