[9fans] changes in 9load

[9fans] changes in 9load

[Fco.J.Ballesteros]

Hi,

	this change makes two things:

	1- lets you use sections in 9load to define environment variables
	2- pass the boot information already parsed form 9load to the kernel.
	   *** This means that this 9load wont boot properly an old kernel.
	   *** An old 9load wont work with a kernel changed by these diffs.
	   *** An old kernel wont work with a 9load changed by these diffs.



Regarding 1, It's useful for things like:

plan9.ini:
...
[!venticonf]
# A file in $venticonf for the boot program
index oldworm
isect /dev/fs/other1
arenas /dev/fs/other

boot.rc:
...
# start venti from conf in plan9.ini
venti -c /env/venticonf

Regarding 2, I thought it was a good time to make the change.

I include first the changes for 9load. Near the end you can find
the changes for /sys/src/9/pc/main.c.

hth

diff -n /n/dump/2003/0515/sys/src/boot/pc /sys/src/boot/pc
diff -n /n/dump/2003/0515/sys/src/boot/pc/apm.c /sys/src/boot/pc/apm.c
/n/dump/2003/0515/sys/src/boot/pc/apm.c:13,14 c /sys/src/boot/pc/apm.c:13,17
< 	if(getconf("apm0") && apm.haveinfo)
< 		changeconf("apm0=ax=%x ebx=%x cx=%x dx=%x di=%x esi=%x\n",
---
> 	char buf[128];
> 	char* p;
>
> 	if(getconf("apm0") && apm.haveinfo){
> 		p = buf + sprint(buf, "ax=%x ebx=%x cx=%x dx=%x di=%x esi=%x",
/n/dump/2003/0515/sys/src/boot/pc/apm.c:15 a /sys/src/boot/pc/apm.c:19,21
> 		*p = 0;
> 		changeconf("apm0", buf);
> 	}
diff -n /n/dump/2003/0515/sys/src/boot/pc/bcom.c /sys/src/boot/pc/bcom.c
/n/dump/2003/0515/sys/src/boot/pc/bcom.c:439 c /sys/src/boot/pc/bcom.c:439
< addconf(char*, ...)
---
> addconf(char*, char*)
diff -n /n/dump/2003/0515/sys/src/boot/pc/conf.c /sys/src/boot/pc/conf.c
/n/dump/2003/0515/sys/src/boot/pc/conf.c:14 c /sys/src/boot/pc/conf.c:14
<  * There are 3584 bytes available at CONFADDR.
---
>  * There are 0x800 bytes available at CONFADDR (up to CPU0PDB).
/n/dump/2003/0515/sys/src/boot/pc/conf.c:18 a /sys/src/boot/pc/conf.c:19
>
/n/dump/2003/0515/sys/src/boot/pc/conf.c:21,22 c /sys/src/boot/pc/conf.c:22
< #define	BOOTARGSLEN	(3584-0x200-BOOTLINELEN)
< #define	MAXCONF		100
---
> #define	BOOTARGSLEN	(0x800-BOOTLINELEN)
/n/dump/2003/0515/sys/src/boot/pc/conf.c:24,26 c /sys/src/boot/pc/conf.c:24,37
< static char *confname[MAXCONF];
< static char *confval[MAXCONF];
< static int nconf;
---
> /*
>  * This must match the struct of the same name in the loaded kernel
>  */
> #define	MAXCONF		64
> typedef struct Bootconf {
> 	char	id[8];
> 	int	nconf;
> 	char	*name[MAXCONF];
> 	char	*val[MAXCONF];
> 	char	args[1];
> } Bootconf;
> static char*	bootargsend;
> static Bootconf*bootargs = (Bootconf*)BOOTARGS;
> static int	confparsed= 0;
/n/dump/2003/0515/sys/src/boot/pc/conf.c:221 c /sys/src/boot/pc/conf.c:232,246
<
---
> 		// add blocks to define environment files
> 		for(i=0; i < nmblock; i++){
> 			mb = &mblock[i];
> 			if (mb->name[0] != '!')
> 				continue;
> 			p += sprint(p, "%s=", mb->name);
> 			// ugly hack: we later translate any \1
> 			// to a \n. Thats how we get multiple lines into
> 			// a single environment variable.
> 			for(n = mb->start; n < mb->end; n++){
> 				p += sprint(p, "%s", line[n]);
> 				*p++ = 1;
> 			}
> 			p += sprint(p, "\n");
> 		}
/n/dump/2003/0515/sys/src/boot/pc/conf.c:274 a /sys/src/boot/pc/conf.c:300,304
> 	if (!confparsed){
> 		if (debug)
> 			print("warning: ignored getconf: %s\n", name);
> 		return nil;
> 	}
/n/dump/2003/0515/sys/src/boot/pc/conf.c:276,277 c /sys/src/boot/pc/conf.c:306,307
< 	for(i = 0; i < nconf; i++)
< 		if(cistrcmp(confname[i], name) == 0)
---
> 	for(i = 0; i < bootargs->nconf; i++)
> 		if(cistrcmp(bootargs->name[i], name) == 0)
/n/dump/2003/0515/sys/src/boot/pc/conf.c:284,286 c /sys/src/boot/pc/conf.c:314,316
< 		for(i = 0; i < nconf; i++)
< 			if(cistrcmp(confname[i], name) == 0)
< 				print("%d. %s\n", ++nmatch, confval[i]);
---
> 		for(i = 0; i < bootargs->nconf; i++)
> 			if(cistrcmp(bootargs->name[i], name) == 0)
> 				print("%d. %s\n", ++nmatch, bootargs->val[i]);
/n/dump/2003/0515/sys/src/boot/pc/conf.c:293,294 c /sys/src/boot/pc/conf.c:323,324
< 		for(i = 0; i < nconf; i++)
< 			if(cistrcmp(confname[i], name) == 0)
---
> 		for(i = 0; i < bootargs->nconf; i++)
> 			if(cistrcmp(bootargs->name[i], name) == 0)
/n/dump/2003/0515/sys/src/boot/pc/conf.c:296 c /sys/src/boot/pc/conf.c:326
< 					return confval[i];
---
> 					return bootargs->val[i];
/n/dump/2003/0515/sys/src/boot/pc/conf.c:300,302 c /sys/src/boot/pc/conf.c:330,332
< 		for(i = 0; i < nconf; i++)
< 			if(cistrcmp(confname[i], name) == 0)
< 				return confval[i];
---
> 		for(i = 0; i < bootargs->nconf; i++)
> 			if(cistrcmp(bootargs->name[i], name) == 0)
> 				return bootargs->val[i];
/n/dump/2003/0515/sys/src/boot/pc/conf.c:312 c /sys/src/boot/pc/conf.c:342
< addconf(char *fmt, ...)
---
> addconf(char* var, char *val)
/n/dump/2003/0515/sys/src/boot/pc/conf.c:314 c /sys/src/boot/pc/conf.c:344,354
< 	donprint(BOOTARGS+strlen(BOOTARGS), BOOTARGS+BOOTARGSLEN, fmt, (&fmt+1));
---
> 	if (!confparsed){
> 		print("warning: ignored addconf: %s=%s\n", var, val);
> 		return;
> 	}
> 	bootargs->name[bootargs->nconf] = bootargsend;
> 	bootargsend += sprint(bootargsend, "%s", var);
> 	*bootargsend++ = 0;
> 	bootargs->val[bootargs->nconf] = bootargsend;
> 	bootargsend += sprint(bootargsend, "%s", val);
> 	*bootargsend++ = 0;
> 	bootargs->nconf++;
/n/dump/2003/0515/sys/src/boot/pc/conf.c:318 c /sys/src/boot/pc/conf.c:358
< changeconf(char *fmt, ...)
---
> changeconf(char *var, char* val)
/n/dump/2003/0515/sys/src/boot/pc/conf.c:320 c /sys/src/boot/pc/conf.c:360
< 	char *p, *q, pref[20], buf[128];
---
> 	int	i;
/n/dump/2003/0515/sys/src/boot/pc/conf.c:322,344 c /sys/src/boot/pc/conf.c:362,378
< 	donprint(buf, buf+sizeof buf, fmt, (&fmt+1));
< 	strncpy(pref+1, buf, 19);
< 	pref[19] = '\0';
< 	if(p = strchr(pref, '='))
< 		*(p+1) = '\0';
< 	else
< 		print("warning: did not change %s in plan9.ini\n", buf);
<
< 	/* find old line by looking for \nwhat= */
< 	pref[0] = '\n';
< 	if(strncmp(BOOTARGS, pref+1, strlen(pref+1)) == 0)
< 		p = BOOTARGS;
< 	else if(p = strstr(BOOTARGS, pref))
< 		p++;
< 	else
< 		p = nil;
<
< 	/* move rest of args up, deleting what= line. */
< 	if(p != nil && (q = strchr(p, '\n')) != nil)
< 		memmove(p, q+1, strlen(q+1)+1);
<
< 	/* add replacement to end */
< 	addconf("%s", buf);
---
> 	if (!confparsed){
> 		print("warning: ignored changeconf: %s=%s\n", var, val);
> 		return;
> 	}
> 	for(i = 0; i < bootargs->nconf; i++){
> 		if (strcmp(bootargs->name[i], var) == 0)
> 			break;
> 	}
> 	if (i == bootargs->nconf){
> 		bootargs->name[i] = bootargsend;
> 		bootargsend += sprint(bootargsend, "%s", var);
> 		*bootargsend++ = 0;
> 		bootargs->nconf++;
> 	}
> 	bootargs->val[i] = bootargsend;
> 	bootargsend += sprint(bootargsend, "%s", val);
> 	*bootargsend++ = 0;
/n/dump/2003/0515/sys/src/boot/pc/conf.c:420,435 c /sys/src/boot/pc/conf.c:454,458
<
< 	/*
< 	 * Keep a copy.
< 	 * We could change this to pass the parsed strings
< 	 * to the booted programme instead of the raw
< 	 * string, then it only gets done once.
< 	 */
< 	if(strncmp(cp, id, sizeof(id))){
< 		memmove(BOOTARGS, id, sizeof(id));
< 		if(n+1+sizeof(id) >= BOOTARGSLEN)
< 			n -= sizeof(id);
< 		memmove(BOOTARGS+sizeof(id), cp, n+1);
< 	}
< 	else
< 		memmove(BOOTARGS, cp, n+1);
<
---
> 	memmove(bootargs->id, id, sizeof(id));
> 	memmove(bootargs->args, cp, n+1);
> 	bootargsend = bootargs->args + n+1;
> 	bootargs->nconf = 0;
> 	cp = bootargs->args;
/n/dump/2003/0515/sys/src/boot/pc/conf.c:437 a /sys/src/boot/pc/conf.c:461,466
> 		if(*line[i] == '!'){			// a file in a
> 			line[i]++;			// variable.
> 			for(q = line[i]; *q; q++)
> 				if (*q == 1)		// ugly hack
> 					*q = '\n';	// see parsemenu.
> 		}
/n/dump/2003/0515/sys/src/boot/pc/conf.c:444,446 c /sys/src/boot/pc/conf.c:473,475
< 		confname[nconf] = line[i];
< 		confval[nconf] = cp;
< 		nconf++;
---
> 		bootargs->name[bootargs->nconf] = line[i];
> 		bootargs->val[bootargs->nconf] = cp;
> 		bootargs->nconf++;
/n/dump/2003/0515/sys/src/boot/pc/conf.c:447 a /sys/src/boot/pc/conf.c:477
> 	confparsed = 1;
/n/dump/2003/0515/sys/src/boot/pc/conf.c:483,484 c /sys/src/boot/pc/conf.c:513,514
< 	for(n = 0; n < nconf; n++){
< 		if(cistrncmp(confname[n], cc, NAMELEN))
---
> 	for(n = 0; n < bootargs->nconf; n++){
> 		if(cistrncmp(bootargs->name[n], cc, NAMELEN))
/n/dump/2003/0515/sys/src/boot/pc/conf.c:487 c /sys/src/boot/pc/conf.c:517
< 		p = confval[n];
---
> 		p = bootargs->val[n];
diff -n /n/dump/2003/0515/sys/src/boot/pc/devsd.c /sys/src/boot/pc/devsd.c
/n/dump/2003/0515/sys/src/boot/pc/devsd.c:431 a /sys/src/boot/pc/devsd.c:432,434
> 	char	name[48];
> 	char	val[128];
> 	char   *bp;
/n/dump/2003/0515/sys/src/boot/pc/devsd.c:440,441 c /sys/src/boot/pc/devsd.c:443,445
<
< 	addconf("%spart=", unit->name);
---
> 	bp = name + sprint(name, "%spart", unit->name);
> 	*bp = 0;
> 	bp = val;
/n/dump/2003/0515/sys/src/boot/pc/devsd.c:443 c /sys/src/boot/pc/devsd.c:447
< 		addconf("%s%s %ld %ld", i==1 ? "" : "/", pp->name,
---
> 		bp += sprint(bp, "%s%s %ld %ld", i==1 ? "" : "/", pp->name,
/n/dump/2003/0515/sys/src/boot/pc/devsd.c:445 c /sys/src/boot/pc/devsd.c:449,450
< 	addconf("\n");
---
> 	*bp = 0;
> 	addconf(name,val);
diff -n /n/dump/2003/0515/sys/src/boot/pc/fns.h /sys/src/boot/pc/fns.h
/n/dump/2003/0515/sys/src/boot/pc/fns.h:2 c /sys/src/boot/pc/fns.h:2
< void	addconf(char*, ...);
---
> void	addconf(char*, char*);
/n/dump/2003/0515/sys/src/boot/pc/fns.h:15 c /sys/src/boot/pc/fns.h:15
< void	changeconf(char*, ...);
---
> void	changeconf(char*, char*);
diff -n /n/dump/2003/0515/sys/src/boot/pc/load.c /sys/src/boot/pc/load.c
/n/dump/2003/0515/sys/src/boot/pc/load.c:209 c /sys/src/boot/pc/load.c:209
< 			if(mp->flag & Fini){
---
> 			if((mp->flag & Fini)){
/n/dump/2003/0515/sys/src/boot/pc/load.c:214 d /sys/src/boot/pc/load.c:213
<
/n/dump/2003/0515/sys/src/boot/pc/load.c:238 a /sys/src/boot/pc/load.c:238
> 	Medium *inimp;
/n/dump/2003/0515/sys/src/boot/pc/load.c:242 a /sys/src/boot/pc/load.c:243
> 	mp = nil;
/n/dump/2003/0515/sys/src/boot/pc/load.c:255 a /sys/src/boot/pc/load.c:257
> 	inimp = nil;
/n/dump/2003/0515/sys/src/boot/pc/load.c:260,262 c /sys/src/boot/pc/load.c:262,263
< 			print("using %s!%s!%s\n", mp->name, mp->part, mp->ini);
< 			dotini(mp->inifs);
< 			break;
---
> 			if (inimp == nil)
> 				inimp = mp;
/n/dump/2003/0515/sys/src/boot/pc/load.c:263 a /sys/src/boot/pc/load.c:265,268
> 	}
> 	if (inimp != nil){
> 		print("using %s!%s!%s\n", mp->name, mp->part, mp->ini);
> 		dotini(inimp->inifs);

This is a change in the manual page.

diff -n /n/dump/2003/0515/sys/man/8/plan9.ini /sys/man/8/plan9.ini
/n/dump/2003/0515/sys/man/8/plan9.ini:770 a /sys/man/8/plan9.ini:771,775
> .LP
> Any block whose name begins with "!" is special. It defines
> a environment variable of the same name (without the "!"). The value
> of the variable is the text of the block. This feature can be
> used to supply small configuration files via environment variables.

These are the diffs for main.c :

diff -n /n/dump/2003/0515/sys/src/9/pc/main.c /sys/src/9/pc/main.c
/n/dump/2003/0515/sys/src/9/pc/main.c:16,18 c /sys/src/9/pc/main.c:16
<  * This will turn into a structure as more is done by the boot loader
<  * (e.g. why parse the .ini file twice?).
<  * There are 3584 bytes available at CONFADDR.
---
>  * There are 0x800 bytes available at CONFADDR.
/n/dump/2003/0515/sys/src/9/pc/main.c:19 a /sys/src/9/pc/main.c:18
>
/n/dump/2003/0515/sys/src/9/pc/main.c:23 c /sys/src/9/pc/main.c:22,26
< #define	BOOTARGSLEN	(4096-0x200-BOOTLINELEN)
---
> #define	BOOTARGSLEN	(0x800-BOOTLINELEN)
>
> /*
>  * This must match the struct of the same name in the loaded kernel
>  */
/n/dump/2003/0515/sys/src/9/pc/main.c:24 a /sys/src/9/pc/main.c:28,34
> typedef struct Bootconf {
> 	char	id[8];
> 	int	nconf;
> 	char	*name[MAXCONF];
> 	char	*val[MAXCONF];
> 	char	args[1];
> } Bootconf;
/n/dump/2003/0515/sys/src/9/pc/main.c:25 a /sys/src/9/pc/main.c:36,37
> static Bootconf*	bootconf = (Bootconf*)BOOTARGS;
>
/n/dump/2003/0515/sys/src/9/pc/main.c:28,30 d /sys/src/9/pc/main.c:39
< char *confname[MAXCONF];
< char *confval[MAXCONF];
< int nconf;
/n/dump/2003/0515/sys/src/9/pc/main.c:33,37 d /sys/src/9/pc/main.c:41
< static void
< options(void)
< {
< 	long i, n;
< 	char *cp, *line[MAXCONF], *p, *q;
/n/dump/2003/0515/sys/src/9/pc/main.c:39,71 d /sys/src/9/pc/main.c:42
< 	/*
< 	 *  parse configuration args from dos file plan9.ini
< 	 */
< 	cp = BOOTARGS;	/* where b.com leaves its config */
< 	cp[BOOTARGSLEN-1] = 0;
<
< 	/*
< 	 * Strip out '\r', change '\t' -> ' '.
< 	 */
< 	p = cp;
< 	for(q = cp; *q; q++){
< 		if(*q == '\r')
< 			continue;
< 		if(*q == '\t')
< 			*q = ' ';
< 		*p++ = *q;
< 	}
< 	*p = 0;
<
< 	n = getfields(cp, line, MAXCONF, 1, "\n");
< 	for(i = 0; i < n; i++){
< 		if(*line[i] == '#')
< 			continue;
< 		cp = strchr(line[i], '=');
< 		if(cp == nil)
< 			continue;
< 		*cp++ = '\0';
< 		confname[nconf] = line[i];
< 		confval[nconf] = cp;
< 		nconf++;
< 	}
< }
<
/n/dump/2003/0515/sys/src/9/pc/main.c:76 d /sys/src/9/pc/main.c:46
< 	options();
/n/dump/2003/0515/sys/src/9/pc/main.c:182,185 c /sys/src/9/pc/main.c:152,155
< 		for(i = 0; i < nconf; i++){
< 			if(confname[i][0] != '*')
< 				ksetenv(confname[i], confval[i], 0);
< 			ksetenv(confname[i], confval[i], 1);
---
> 		for(i = 0; i < bootconf->nconf; i++){
> 			if(bootconf->name[i][0] != '*')
> 				ksetenv(bootconf->name[i], bootconf->val[i], 0);
> 			ksetenv(bootconf->name[i], bootconf->val[i], 1);
/n/dump/2003/0515/sys/src/9/pc/main.c:307,309 c /sys/src/9/pc/main.c:277,279
< 	for(i = 0; i < nconf; i++)
< 		if(cistrcmp(confname[i], name) == 0)
< 			return confval[i];
---
> 	for(i = 0; i < bootconf->nconf; i++)
> 		if(cistrcmp(bootconf->name[i], name) == 0)
> 			return bootconf->val[i];

Re: [9fans] changes in 9load

[Russ Cox]

I might.  I will check tonight.

Re: [9fans] changes in 9load

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 74 bytes --]

If you or anyone else want the whole files instead of diffs,
let me know.

[-- Attachment #2: Type: message/rfc822, Size: 1224 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] changes in 9load
Date: Wed, 21 May 2003 10:58:58 -0400
Message-ID: <21b549489a519256bb545fd1ee7b3a56@plan9.bell-labs.com>

I might.  I will check tonight.

Re: [9fans] changes in 9load

[Russ Cox]

[The "I might.  I will check tonight." was a response to a
different, private email from Nemo.  Sorry.  Here's
a real response to make up for it.]

I'd rather not see the multiline environment variable hack
go into plan9.ini.  (Though if it did, I'd name the sections [$var]
instead of [!var].)

Plan9.ini used to be this really complex mess that you had to
fiddle with quite a bit to get your system to boot.  Now it's this
really complex mess that you only have to fiddle with a small
amount to get your system to boot.  A plan9.ini for a typical
configuration only needs to set mouseport, vgasize, and monitor.
All three of these could be stored in the file system proper instead,
making plan9.ini completely optional.  I haven't done this because
I'd rather see the variables go away entirely.  If we autodetect the
mouse and probe the video card for monitor and a good vgasize,
that gets us most of the way there.  If aux/vga can handle resizing
the screen on the fly, we're all the way there.

There will always be a plan9.ini.  There has to be some way
to tell the kernel things that it doesn't know how to learn for itself.
But I want to see plan9.ini get more and more optional.
Unless you're doing something complicated, you shouldn't
have to know about it.

One eventual goal for fossil is to replace kfs.  This means
everyone will be running fossil (with or without venti).  Needing
to put configuration info in plan9.ini suddenly makes plan9.ini
a lot less optional.  Thus I am fairly opposed to having it there.
Instead, I would like to see the configuration information for
venti and fossil put at the beginning of their disks, so that
you can just tell it the disk and you're off and running.  With
some sensible conventions naming the disks we could boot
an IDE system with no plan9.ini at all.

Long ago, plan9.ini had syntax for defining multiline
environment variables.  It was dropped at one point because
it wasn't found to be generally useful.  I hope this continues
to be the case.  If we need to store that much in an environment
variable, it means we've built the system in such a way that
it requires too much configuration.

Russ

[9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[boyd, rounin]

i have a VAIO with an ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display.

i just wanna turn it into a simple character mode server [fs/firewall/auth/etc].

what is the magic i need to construct the boot diskette?

and yes, it's another USB floppy install, but i can cope with that.

all i really need is cga, but to do the install, its a bit 'sporty'.

Re: [9fans] changes in 9load

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

I wanted the variables to start fossil/venti without having to
recompile the kernel. I also would prefer to put the conf in the
disks they're using (In fact I think I suggested it some time ago).
The thing is that I wouldn't like to change fossil/venti, because I
don't know them that well, and I'd prefer that change to be well-done
(for example, I'd expect the changed fossil/venti to be able to use
partitions from old ones).

But in the mean time, I think I'll keep the support for multiline
vars (which I'll be using just in our file server). I'm quite tired
of recompiling the kernel because of a change in the configuration.

I think the same can be the case for others, althought of course
that means that their fs plan9.ini would be `mandatory' as well.

But it's likely we all agree that once there's no need to use those
configuration files, multiline vars would become useless.

Regarding the other change, it seems better to parse the arguments once
and pass them already parsed to the kernel.

thanks for your reply

[-- Attachment #2: Type: message/rfc822, Size: 3390 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] changes in 9load
Date: Wed, 21 May 2003 11:22:24 -0400
Message-ID: <378f47e82d876408e51c03e6eb666d80@plan9.bell-labs.com>

[The "I might.  I will check tonight." was a response to a
different, private email from Nemo.  Sorry.  Here's
a real response to make up for it.]

I'd rather not see the multiline environment variable hack
go into plan9.ini.  (Though if it did, I'd name the sections [$var]
instead of [!var].)

Plan9.ini used to be this really complex mess that you had to
fiddle with quite a bit to get your system to boot.  Now it's this
really complex mess that you only have to fiddle with a small
amount to get your system to boot.  A plan9.ini for a typical
configuration only needs to set mouseport, vgasize, and monitor.
All three of these could be stored in the file system proper instead,
making plan9.ini completely optional.  I haven't done this because
I'd rather see the variables go away entirely.  If we autodetect the
mouse and probe the video card for monitor and a good vgasize,
that gets us most of the way there.  If aux/vga can handle resizing
the screen on the fly, we're all the way there.

There will always be a plan9.ini.  There has to be some way
to tell the kernel things that it doesn't know how to learn for itself.
But I want to see plan9.ini get more and more optional.
Unless you're doing something complicated, you shouldn't
have to know about it.

One eventual goal for fossil is to replace kfs.  This means
everyone will be running fossil (with or without venti).  Needing
to put configuration info in plan9.ini suddenly makes plan9.ini
a lot less optional.  Thus I am fairly opposed to having it there.
Instead, I would like to see the configuration information for
venti and fossil put at the beginning of their disks, so that
you can just tell it the disk and you're off and running.  With
some sensible conventions naming the disks we could boot
an IDE system with no plan9.ini at all.

Long ago, plan9.ini had syntax for defining multiline
environment variables.  It was dropped at one point because
it wasn't found to be generally useful.  I hope this continues
to be the case.  If we need to store that much in an environment
variable, it means we've built the system in such a way that
it requires too much configuration.

Russ

Re: [9fans] changes in 9load

[northern snowfall]

>
>
>  If we need to store that much in an environment
>variable, it means we've built the system in such a way that
>it requires too much configuration.
>
I agree, 100%

>

Re: [9fans] changes in 9load

[Lucio De Re]

On Wed, May 21, 2003 at 11:22:24AM -0400, Russ Cox wrote:
>
> I'd rather not see the multiline environment variable hack
> go into plan9.ini.  (Though if it did, I'd name the sections [$var]
> instead of [!var].)
>
> [ Etc. ]

I agree with Russ's sentiments, possibly not for the exact same
reasons.

I couldn't quite find an opportunity earlier, but I'd like to add
a small thought here.  I would have brought it up eventually,
probably after some experimentation, this has given me the chance:

I like the /boot idea.  I'd like it even more if its contents could
be discarded, or maybe made kernel-loadable for real convenience,
but as it stands it is already pretty cool.

In fact, my thinking was that one may be able to construct an AUTH
kernel with its entire complement of tools in /boot, and only the
auth data on disk outside the kernel.  As I mentioned, I was going
to try this out before bringing it up, but perhaps somebody else
wants to give it a try while I'm busy with other, more mundane
activities.

Given such an option, I'd also rather keep the mandatory information
in plan9.ini and its complexity to a bare minimum.  If I understood
Nemo's proposal, it attempts to move as much out of /boot as can
be described by some option in plan9.ini.  Of itself, the idea has
its own merits, but it seems to me to suggest that /boot should be
deprecated, whereas I believe its possibilities should be explored
further instead.

++L

Re: [9fans] changes in 9load

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

Not quite. Just to clarify the aim of the code I sent:

My proposal was to keep in plan9.ini just that part of /boot
that you consider configuration (venti.conf, fossil.conf mainly).
Otherwise, I keep /boot as it was, readonly, with all the tools in.
However, I'm putting the configuration for fs, fossil, and venti into
plan9.ini. (Now that the alternative is to put that in /boot).

I also thought of making /boot rw, but that would be much more clumsy that
putting the config somewhere else. When thinking about where to put it,
I considered that in fact I had to keep a plan9.ini everywhere, and I
just decided to put the config for the file server in that place too (instead
of adding a different place).

[-- Attachment #2: Type: message/rfc822, Size: 3307 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] changes in 9load
Date: Wed, 21 May 2003 19:06:58 +0200
Message-ID: <20030521190658.Z7647@cackle.proxima.alt.za>

On Wed, May 21, 2003 at 11:22:24AM -0400, Russ Cox wrote:
>
> I'd rather not see the multiline environment variable hack
> go into plan9.ini.  (Though if it did, I'd name the sections [$var]
> instead of [!var].)
>
> [ Etc. ]

I agree with Russ's sentiments, possibly not for the exact same
reasons.

I couldn't quite find an opportunity earlier, but I'd like to add
a small thought here.  I would have brought it up eventually,
probably after some experimentation, this has given me the chance:

I like the /boot idea.  I'd like it even more if its contents could
be discarded, or maybe made kernel-loadable for real convenience,
but as it stands it is already pretty cool.

In fact, my thinking was that one may be able to construct an AUTH
kernel with its entire complement of tools in /boot, and only the
auth data on disk outside the kernel.  As I mentioned, I was going
to try this out before bringing it up, but perhaps somebody else
wants to give it a try while I'm busy with other, more mundane
activities.

Given such an option, I'd also rather keep the mandatory information
in plan9.ini and its complexity to a bare minimum.  If I understood
Nemo's proposal, it attempts to move as much out of /boot as can
be described by some option in plan9.ini.  Of itself, the idea has
its own merits, but it seems to me to suggest that /boot should be
deprecated, whereas I believe its possibilities should be explored
further instead.

++L

Re: [9fans] changes in 9load

[Russ Cox]

> Regarding the other change, it seems better to parse the arguments once
> and pass them already parsed to the kernel.

That's very true (hence the source comment) but the main factor is pain.
It requires updating everyone's 9load and kernel simultaneously (at least
the way you've done it), and that's just not easy for a lot of people.
We have home users at Bell Labs who use Plan 9 as a means to do other
work and aren't really interested in maintaining their home systems.
I'll leave the double parsing in until there's a different compelling
reason to force them to update their 9loads.

Russ

Re: [9fans] changes in 9load

[Lucio De Re]

On Wed, May 21, 2003 at 07:15:41PM +0200, Fco.J.Ballesteros wrote:
>
> Not quite. Just to clarify the aim of the code I sent:
>
I confess to reading your message somewhat lightly.  I really was
being rather opportunistic in hoping to vent <grin> my idea of a
self-contained AUTH server.

> My proposal was to keep in plan9.ini just that part of /boot
> that you consider configuration (venti.conf, fossil.conf mainly).
> Otherwise, I keep /boot as it was, readonly, with all the tools in.
> However, I'm putting the configuration for fs, fossil, and venti into
> plan9.ini. (Now that the alternative is to put that in /boot).
>
And the big difference is in /boot being immutable except with
great pain.  I think your intent is certainly commendable :-)

> I also thought of making /boot rw, but that would be much more clumsy that
> putting the config somewhere else. When thinking about where to put it,
> I considered that in fact I had to keep a plan9.ini everywhere, and I
> just decided to put the config for the file server in that place too (instead
> of adding a different place).

Yeah.  I also considered a rw /boot, but, without even looking, I
assumed it would be a bitch, at best.  Being read-only is of course
a security advantage.  On the other hand, could a script in /boot
not read the configuration files from the boot medium instead of
inheriting them off the "environment"?

I do like the thought that with brucee's extensions we could make
/boot the location of loadable kernel modules to meet your desires
at least half way.

On that score, could these extensions be made available, maybe
someone will finish them if they still need some effort?

++L

Re: [9fans] changes in 9load

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

The boot script can read the config from wherever you want.
Just use
whatever -c /boot/whateverconf
instead of
whatever -c /env/whateverconf

[-- Attachment #2: Type: message/rfc822, Size: 3540 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] changes in 9load
Date: Wed, 21 May 2003 19:25:02 +0200
Message-ID: <20030521192502.C7647@cackle.proxima.alt.za>

On Wed, May 21, 2003 at 07:15:41PM +0200, Fco.J.Ballesteros wrote:
>
> Not quite. Just to clarify the aim of the code I sent:
>
I confess to reading your message somewhat lightly.  I really was
being rather opportunistic in hoping to vent <grin> my idea of a
self-contained AUTH server.

> My proposal was to keep in plan9.ini just that part of /boot
> that you consider configuration (venti.conf, fossil.conf mainly).
> Otherwise, I keep /boot as it was, readonly, with all the tools in.
> However, I'm putting the configuration for fs, fossil, and venti into
> plan9.ini. (Now that the alternative is to put that in /boot).
>
And the big difference is in /boot being immutable except with
great pain.  I think your intent is certainly commendable :-)

> I also thought of making /boot rw, but that would be much more clumsy that
> putting the config somewhere else. When thinking about where to put it,
> I considered that in fact I had to keep a plan9.ini everywhere, and I
> just decided to put the config for the file server in that place too (instead
> of adding a different place).

Yeah.  I also considered a rw /boot, but, without even looking, I
assumed it would be a bitch, at best.  Being read-only is of course
a security advantage.  On the other hand, could a script in /boot
not read the configuration files from the boot medium instead of
inheriting them off the "environment"?

I do like the thought that with brucee's extensions we could make
/boot the location of loadable kernel modules to meet your desires
at least half way.

On that score, could these extensions be made available, maybe
someone will finish them if they still need some effort?

++L

Re: [9fans] changes in 9load

[Russ Cox]

> Yeah.  I also considered a rw /boot, but, without even looking, I
> assumed it would be a bitch, at best.  Being read-only is of course
> a security advantage.  On the other hand, could a script in /boot
> not read the configuration files from the boot medium instead of
> inheriting them off the "environment"?

What would a rw /boot mean?  Changing it certainly
wouldn't change the kernel image (wherever it may
have been picked up from), so you might as well use
ramfs if you want an in-memory rw file system.

Russ

Re: [9fans] changes in 9load

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

I meant a file system to access the /boot portion in the kernel image.
But I think that's both clumsy and wrong (because you might change the kernel
without doing a mk) and discarded the idea soon after considering it.

[-- Attachment #2: Type: message/rfc822, Size: 1880 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] changes in 9load
Date: Wed, 21 May 2003 13:35:17 -0400
Message-ID: <90b20611bddbc6da6a3a70d5d136263a@plan9.bell-labs.com>

> Yeah.  I also considered a rw /boot, but, without even looking, I
> assumed it would be a bitch, at best.  Being read-only is of course
> a security advantage.  On the other hand, could a script in /boot
> not read the configuration files from the boot medium instead of
> inheriting them off the "environment"?

What would a rw /boot mean?  Changing it certainly
wouldn't change the kernel image (wherever it may
have been picked up from), so you might as well use
ramfs if you want an in-memory rw file system.

Russ

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Russ Cox]

I think I made all the necessary changes to do a text mode install.
When you boot, you get dropped out to a prompt and then you run
inst/textonly.

I think.

Russ

Re: [9fans] changes in 9load

[Lucio De Re]

On Wed, May 21, 2003 at 01:35:17PM -0400, Russ Cox wrote:
>
> What would a rw /boot mean?  Changing it certainly
> wouldn't change the kernel image (wherever it may
> have been picked up from), so you might as well use
> ramfs if you want an in-memory rw file system.
>
In an embedded system, for example, you could release the memory
allocated to modules you no longer need.  You'd certainly not want
that reflected in the permanent storage image, but it could make
a significant difference where memory is at a premium.

That's really the only purpose I could imagine.  Being able to
change data in /boot sounds like great complication with very little
gain.

++L

PS: Often the argument that memory and computing cycles are cheap
resources is raised here and elsewhere.  My take is that this is
certainly the case, but that making efficient use of resources is
a better investment than relying on low cost.  The difference
becomes significant when utilisation soares and the inefficiencies
bring a system to its knees.  IMHO reliance on low cost leads to
environmental waste, specially in an economic sense.

Not that I don't understand the danger of premature optimisation
:-)

Re: [9fans] changes in 9load

[Russ Cox]

> In an embedded system, for example, you could release the memory
> allocated to modules you no longer need.  You'd certainly not want
> that reflected in the permanent storage image, but it could make
> a significant difference where memory is at a premium.

This isn't a r/w /boot.  This is a removable /boot.
That makes a lot more sense.

Re: [9fans] changes in 9load

[Lucio De Re]

On Wed, May 21, 2003 at 01:51:00PM -0400, Russ Cox wrote:
>
> This isn't a r/w /boot.  This is a removable /boot.
> That makes a lot more sense.

Yes.  But I assumed one might be selective, based on needing rw
permission on /boot to be able to rm a component.  Except that the
effort isn't justified if taken to its logical extreme.  Hence the
(un)loadable kernel modules.

++L

Re: [9fans] changes in 9load

[Lucio De Re]

On Wed, May 21, 2003 at 07:39:57PM +0200, Fco.J.Ballesteros wrote:
>
> I meant a file system to access the /boot portion in the kernel image.
> But I think that's both clumsy and wrong (because you might change the kernel
> without doing a mk) and discarded the idea soon after considering it.

I don't like the thought of manipulating a disk image in this
fashion, myself.  But I really think your objective could be
achieved, as you point out, by storing the information in a config
file _other_ than plan9.ini on the boot medium.  Maybe a /n/init
mountpoint?  Would this really be less flexible than having the
knowledge in 9load?

++L

Re: [9fans] changes in 9load

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

The point it that it would be yet another place where you
have to put configuration in.

If configuration doesn't go away (eg by putting it in the thing
being handled, like in the disk used by venti), I prefer to
keep it all just in one place. I mean, If right now,
if I get 9load and a plan9.ini, I'm all set.

[-- Attachment #2: Type: message/rfc822, Size: 2492 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] changes in 9load
Date: Wed, 21 May 2003 20:03:16 +0200
Message-ID: <20030521200315.H7647@cackle.proxima.alt.za>

On Wed, May 21, 2003 at 07:39:57PM +0200, Fco.J.Ballesteros wrote:
>
> I meant a file system to access the /boot portion in the kernel image.
> But I think that's both clumsy and wrong (because you might change the kernel
> without doing a mk) and discarded the idea soon after considering it.

I don't like the thought of manipulating a disk image in this
fashion, myself.  But I really think your objective could be
achieved, as you point out, by storing the information in a config
file _other_ than plan9.ini on the boot medium.  Maybe a /n/init
mountpoint?  Would this really be less flexible than having the
knowledge in 9load?

++L

Re: [9fans] changes in 9load

[Lucio De Re]

On Wed, May 21, 2003 at 08:11:36PM +0200, Fco.J.Ballesteros wrote:
>
> The point it that it would be yet another place where you
> have to put configuration in.
>
I guess it's a judgement call.  I do see your point.

++L

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[boyd, rounin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

"Russ Cox" <rsc@plan9.bell-labs.com> a �crit dans le message de
news:2aae62524e8ca87f9fb6bbaea9b9b756@plan9.bell-labs.com...
> I think I made all the necessary changes to do a text mode install.
> When you boot, you get dropped out to a prompt and then you run
> inst/textonly.
>
> I think.

did you test it?

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Philippe Anel]

At 08:46 22/05/03 +0000, you wrote:
>"Russ Cox" <rsc@plan9.bell-labs.com> a écrit dans le message de
>news:2aae62524e8ca87f9fb6bbaea9b9b756@plan9.bell-labs.com...
> > I think I made all the necessary changes to do a text mode install.
> > When you boot, you get dropped out to a prompt and then you run
> > inst/textonly.
> >
> > I think.
>
>did you test it?

I tested it a few weeks ago, and it worked.

    Philippe,

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Russ Cox]

> did you test it?

i don't remember.  it was long ago.

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Adrian Tritschler]

Philippe Anel wrote:

> At 08:46 22/05/03 +0000, you wrote:
> 
>> "Russ Cox" <rsc@plan9.bell-labs.com> a écrit dans le message de
>> news:2aae62524e8ca87f9fb6bbaea9b9b756@plan9.bell-labs.com...
>> > I think I made all the necessary changes to do a text mode install.
>> > When you boot, you get dropped out to a prompt and then you run
>> > inst/textonly.
>> >
>> > I think.
>>
>> did you test it?

I've run an install from inst/textonly and had no problems with it.

I have had problem arise when the install floppy partially detects the 
video and tries/fails to load rio, leaving a garbled screen and no way 
of forcing a text-only install

Current status:

My Plan9 network (three bits of hardware intended for other users)

* Auth/CPU/KFS, runs Pegasus and Aquarela
* pccpu, diskless
* T21 laptop, drawterm under WinXP, or networkless as P9 terminal :-(

	Adrian

---------------------------------------------------------------
Adrian Tritschler    mailto:Adrian.Tritschler@its.monash.edu.au
Latitude 38°S, Longitude 145°E, Altitude 50m,      Shoe size 44
---------------------------------------------------------------

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Russ Cox]

> Pegasus

What is Pegasus?

> * T21 laptop, drawterm under WinXP, or networkless as P9 terminal :-(

What ethernet is on your T21 that it's networkless?

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Sape Mullender]

>> Pegasus
>
> What is Pegasus?

Pegasus was a highly successful Esprit project carried out by the Universities
of Cambridge and Twente.  It produced Nemesis, one of the most interesting
operating systems of all time.

(couldn't resist)

	Sape

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Dan Cross]

"Russ Cox" <rsc@plan9.bell-labs.com> writes:
>
> > Pegasus
>
> What is Pegasus?

Kenji Arisawa's web server.  See http://plan9.aichi-u.ac.jp/ (mostly
in Japanese).

I'm more curious about what aquarela is.

	- Dan C.

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Russ Cox]

> I'm more curious about what aquarela is.

Nigel announced this already.  http://www.9fs.org/dist/aquarela

Re: [9fans] VAIO ATI RAGE MOBILITY-M1 AGP 1024x768x16 lcd display

[Dan Cross]

> Nigel announced this already.  http://www.9fs.org/dist/aquarela

Ahh, the CIFS server.  I'd forgotten the name.  Thanks.

	- Dan C.