[9fans] ideas for a new install procedure

[9fans] ideas for a new install procedure

[Fco.J.Ballesteros]

One way would be to ship a kernel with just enough to download another
kernel from the network (like the 50M distribution file). Then
use that kernel to boot the real installer.

I think I like this more than I like dynamic modules for the kernel
(which I think I read are being included). But if that's the case, these
modules can also be downloaded either from the net or from wherever the
50M dist file is being downloaded.

Also, is 9pcdisk.gz using bzip2? If not, bzip2 can reach higher
compression rates. Still remember when I had to use `make bzImage'
instead of `make zImage' for linux...

hth

RE: [9fans] ideas for a new install procedure

[Jason Gurtz]

> Also, is 9pcdisk.gz using bzip2? If not, bzip2 can reach higher
> compression rates. Still remember when I had to use `make bzImage'
> instead of `make zImage' for linux...

Not to minimize the (IMHO good) suggestion of using bzip2.  I must point
out that it is quite the common misconception that bzImage uses bzip2.
the "b" stands for  big.  It still uses gzip.  The kernel docs make that
quite clear.

~Jason

--

Re: [9fans] ideas for a new install procedure

[Dan Cross]

In article <20011114081504.7024919A27@mail.cse.psu.edu> you write:
>One way would be to ship a kernel with just enough to download another
>kernel from the network (like the 50M distribution file). Then
>use that kernel to boot the real installer.

Don't you have a bootstrapping problem, though?  How do you get to
the network to get the bigger kernel unless you compile a lot of
drivers into the smallish one?  It seems that drivers are what's
making the kernel too big.

One possibility might be to strip out ``dead'' drivers for old or
rarely used components.  Or put drivers for older components in a
different kernel.

>I think I like this more than I like dynamic modules for the kernel
>(which I think I read are being included). But if that's the case, these
>modules can also be downloaded either from the net or from wherever the
>50M dist file is being downloaded.

I'm not sure I dig the idea of loadable drivers myself.  And
somebody's doing perl.  There goes the neighborhood.

>Also, is 9pcdisk.gz using bzip2? If not, bzip2 can reach higher
>compression rates. Still remember when I had to use `make bzImage'
>instead of `make zImage' for linux...

I'm not sure that the gain using bzip2 will be enough to solve the
problem.  Multiple floppies will work, but are kind of an ugly solution
(but not all solutions have to be beautiful; bootstrapping is ugly in
general).  Eventually, the kernel might get too big for a single
floppy, though, and then what?  Will we ever have that many drivers?

I still like the idea of linking a custom kernel and putting that onto
the download floppy best.  It seems like the most likely to scale
temporally.

However, as Nemo says, a machine with current sources (or close to
current) that people can login to over the Internet would be really
very cool.

	- Dan C.

(btw- is this the appropriate time to ask for 9pccd and PXE bootloader
support?  :-)

RE: [9fans] ideas for a new install procedure

[Jason Gurtz]

> Well, don't hold your breath; I don't have any way to test the
> VGA interface right now, and likely won't for a couple of weeks.
> Boo....  :-(

Oh well, I'm sure I have a spare Mach 64 laying around somewhere.

~Jason

--

Re: [9fans] ideas for a new install procedure

[Sam Hopkins]

On Thursday 15 November 2001 05:41, you wrote:
> > I haven't been impressed with bzip2.
>
> There's also lzop for when speed is more important than compression.
> Not useful for boot floppies, but may be on another occasion.

... or lzip for a fine balance between both needs.
lzip.sourceforge.net

Sam

Re: [9fans] ideas for a new install procedure

[Ralph Corderoy]

> I haven't been impressed with bzip2.

There's also lzop for when speed is more important than compression.
Not useful for boot floppies, but may be on another occasion.

Cheers,


Ralph.

Re: [9fans] ideas for a new install procedure

[Dan Cross]

In article <HBEEKNPPKIMFLJHGHNHMIEAMCGAA.jason@tommyk.com> you write:
>> I volunteer to write drivers for the SiS900 ethernet (done, sans a
>> few small things), the SiS5597 VGA interface (working on it), and
>> the C-Media audio chip in the NIC (I forget the exact model number).
>
>YAY!, I just picked up a replacment MB for an ageing fic-2011 that
>causes a deep freeze every few weeks.  It cost ~100USD including K6-2
>550Mhz and has all the sis stuff on there.  Now I don't have to go
>looking for a NIC and Video Card

Well, don't hold your breath; I don't have any way to test the
VGA interface right now, and likely won't for a couple of weeks.
Boo....  :-(

	- Dan C.

Re: [9fans] ideas for a new install procedure

[Dan Cross]

In article <20011114223627.F3A0F199EA@mail.cse.psu.edu> you write:
>Umm, everything _is_ based on PCM audio samples.

What I mean is making that explicit, as opposed to being almost
an afterthought (which is the way it seems from reading the various
audio related man pages).

>Divorcing devaudio from the soundblaster isn't
>a bad idea by itself though.

That too....

>(And while I'm writing, the interface for things
>like 9pccd isn't quite as uniform and consistent
>as you might guess from my posting.  It only worked
>because someone anticipated the need to do that.
>Grep for 9660srv in /sys/src/9/port/*.)

Shucks.  Rain on my parade, why don't you.

	- Dan C.

Re: [9fans] ideas for a new install procedure

[Russ Cox]

the root file servers are all aliased as kfs so that /boot
(see /sys/src/9/boot) can just exec /kfs.  they used to be
called /fs, but then we kept killing it after upas/fs came
along.  that was bad.

to be a root file system server, you have to accept the -f and -s
flags that dossrv, 9660srv, kfs, etc. all do.

vdfs is like bzfs and gzfs but used vdsqueeze, a compression
program that we don't have the rights to distribute.
(at&t does, though, and it's in david korn's big unix tools kit.)

russ

Re: [9fans] ideas for a new install procedure

[Russ Cox]

the root file servers are all aliased as kfs so that /boot
(see /sys/src/9/boot) can just exec /kfs.  they used to be
called /fs, but then we kept killing it after upas/fs came
along.  that was bad.

to be a root file system server, you have to accept the -f and -s
flags that dossrv, 9660srv, kfs, etc. all do.

vdfs is like bzfs and gzfs but used vdsqueeze, a compression
program that we don't have the rights to distribute.
(at&t does, though, and it's in

Re: [9fans] ideas for a new install procedure

[anothy]

// ...the interface for things like 9pccd isn't quite as uniform and
// consistent as you might guess...

thanks, since i was just gonna ask. so how do we throw something
different in as the root? what needs to be true of a given program for
it to be suitable for root service? it looks like ones that provide the
file system themselves are aliased to kfs; is this correct? if a given
program can provide the root file system itself, is duplicating what's
done for 9660srv sufficient?

oh, and what's vdfs?
ア

RE: [9fans] ideas for a new install procedure

[Jason Gurtz]

> I volunteer to write drivers for the SiS900 ethernet (done, sans a
> few small things), the SiS5597 VGA interface (working on it), and
> the C-Media audio chip in the NIC (I forget the exact model number).

YAY!, I just picked up a replacment MB for an ageing fic-2011 that
causes a deep freeze every few weeks.  It cost ~100USD including K6-2
550Mhz and has all the sis stuff on there.  Now I don't have to go
looking for a NIC and Video Card

~Jason

--

Re: [9fans] ideas for a new install procedure

[Russ Cox]

Umm, everything _is_ based on PCM audio samples.
Divorcing devaudio from the soundblaster isn't
a bad idea by itself though.

(And while I'm writing, the interface for things
like 9pccd isn't quite as uniform and consistent
as you might guess from my posting.  It only worked
because someone anticipated the need to do that.
Grep for 9660srv in /sys/src/9/port/*.)

Russ

Re: [9fans] ideas for a new install procedure

[Dan Cross]

In article <20011114213222.E1198199ED@mail.cse.psu.edu> you write:
>actually, i'd say the real problem is writing all the required
>drivers in the first place, not the dynamic loading of
>the same.  no, that's not right.  the real problem is getting
>the data required to be able to write the drivers.

I disagree.  With no mechanism to deliver those drivers, they
don't do much good, nor does obtaining the information needed
to write them.  :-)

>so, who volunteers to write what?

I volunteer to write drivers for the SiS900 ethernet (done, sans a
few small things), the SiS5597 VGA interface (working on it), and
the C-Media audio chip in the NIC (I forget the exact model number).
I'd also like to look into the CS4624 audio chip in the Thinkpad,
and maybe into porting (as opposed to rewriting) the Adaptec 78xxx
driver from Unix.  The last is probably more ambitious than I am
prepared to work on right now.  As part of the audio chip support,
I plan to utterly divorce the audio framework from the soundblaster
family, and say that everything is based on PCM audio samples,
instead.

>perhaps a list of need-driver/will-attempt on the wiki?

That's an excellent idea.

	- Dan C.

Re: [9fans] ideas for a new install procedure

[forsyth]

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

this is what i used
cpu% diff pcdisk pccd
52,53c52,53
< 	cfs.root
< 	kfs.root
---
> #	cfs.root
> #	kfs.root
54a55
> 	9660srv.root
93,94c94
< boot boot #S/sdC0/
< 	il
---
> boot glenda #S/sdC1/data

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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] ideas for a new install procedure
Date: Wed, 14 Nov 2001 15:03:15 -0500
Message-ID: <20011114200333.D74B5199ED@mail.cse.psu.edu>

9pccd is trivial.

change kfs.root to 9660srv.root in
your kernel config file and recompile.

Re: [9fans] ideas for a new install procedure

[forsyth]

actually, i'd say the real problem is writing all the required
drivers in the first place, not the dynamic loading of
the same.  no, that's not right.  the real problem is getting
the data required to be able to write the drivers.

so, who volunteers to write what?
perhaps a list of need-driver/will-attempt on the wiki?

Re: [9fans] ideas for a new install procedure

[Dan Cross]

In article <20011114200333.D74B5199ED@mail.cse.psu.edu> you write:
>9pccd is trivial.
>
>change kfs.root to 9660srv.root in
>your kernel config file and recompile.

Excellent!  Thanks Russ.  Wow, never underestimate the power of
a simple and consistent interface.

	- Dan C.

Re: [9fans] ideas for a new install procedure

[Russ Cox]

9pccd is trivial.

change kfs.root to 9660srv.root in
your kernel config file and recompile.

Re: [9fans] ideas for a new install procedure

[Fco.J.Ballesteros]

9pcdisk size is 1363915 for me.
9pcdisk.bz2 is 493175

Don't know if that rate would be enough to make new kernels fit
into the installation floppy.

Re: [9fans] ideas for a new install procedure

[William Josephson]

On Wed, Nov 14, 2001 at 02:44:53AM -0800, geoff@collyer.net wrote:
> 9pc*.gz are compressed with gzip:

> I haven't been impressed with bzip2.  It consumes a lot more cpu time
> and doesn't seem to yield correspondingly better compression.  The

Depends on what you are compressing.  BWT can make a very substantial
difference on the right kind of input.  It isn't for everything,
though.

 -WJ

Re: [9fans] ideas for a new install procedure

[geoff]

9pc*.gz are compressed with gzip:

; ed - /sys/src/9/pc/mkfile
/gzip/;-,.p
$p$CONF.gz: $p$CONF
	strip < $p$CONF | gzip -9 > $p$CONF.gz

I haven't been impressed with bzip2.  It consumes a lot more cpu time
and doesn't seem to yield correspondingly better compression.  The
comparison I made was compressing the first 1GB of an image of a
heavily-used 4.5 GB disk, using gzip, gzip -9, bzip2 and bzip2 -9.  It
compressed down to about 45% of original size.  -9 never helped much
(maybe 5% at most) and bzip2 consumed about an order of magnitude more
cpu time for very little gain, maybe another 5%.  I like to get my
gigabytes compressed while I'm still young enough to enjoy them, so
I've pretty much given up on bzip2.  If you had to shave a few
kilobytes off a compressed kernel to make the install kit fit on a
floppy, it might be worth using bzip2 -9.