From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Subject: Re: [9fans] 9vx and local file systems
From: "Russ Cox" <rsc@swtch.com>
Date: Wed, 23 Jul 2008 13:51:58 -0400
In-Reply-To: <072320081440.1316.488742E0000663F50000052422243651029B0A02D2089B9A019C04040A0DBF9B9D0E9A9B9C040D@att.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080723174936.CA1F71E8C1F@holo.morphisms.net>
Topicbox-Message-UUID: efb3b714-ead3-11e9-9d60-3106f5b1d025

> I'm doing all of this on Linux.  Since then, I have seen
> it lock up when running from a fossil/venti root and #Z
> not bound.  I can't support it with statistics, but my gut
> reaction is that it's less often though.

If this happens again, then running "thread apply all where 20"
in gdb should help determine what's going on.

> 9vx read a plan9.ini file.  So I've been folding 9load's
> ini file reader into 9vx.  This is not so much massaging
> as with part.c, but liposuction.

I would be inclined to do away with full plan9.ini
parsing and just read a file containing

	name=value

lines that get stuffed immediately into the config
environment (ksetenv).  Or just pass a couple
name=value pairs on the command line.

Allowing the plan9.ini disease to spread seems
like a lose.

Russ