Re: [9fans] Replacing 9load

[Russ Cox <rsc@swtch.com>]

Here is the context, which I think is relevant.  And if not,
it is at least illuminating of how these IRC discussions
snowball into beliefs that are far from the truth.


kuroneko  ACTION swears at 9load, old plan9 isos, and other
         issues
         rather than migrating my old kenfs, I have to take
         more drastic measures. *sigh*

uriel     oh, 9load, the horror, the horror :)

kuroneko  I swear, 9load is on my list...

uriel     "hit list"?

kuroneko  *nods*

uriel     hehe :)

kuroneko  9load must die.

uriel     kuroneko: take care of 9load, and I will owe you quite
         a few beers

kuroneko  its on my list after establish world peace.

uriel     hehehe...

kuroneko  it may get bumped up a few notches once I get sparc
         or mips working.

uriel     don't worry, I'm taking care of world peace
         ;)

lantis    ^^

kuroneko  but 9load must die.

uriel     ACTION says amen

kuroneko  I am really unhappy with the fact that 9load appears
         to pass information onto the sym53cxxx driver
         it means that the sym53cxxx driver will not work on
         non-x86
         and I'm sure I've outlined the other reasons why I
         feel so strongly about 9load's death...

...

kuroneko  9load needs to go away.

vt3       ok, but what replaces it?

kuroneko  x86 needs to either switch to booting via multiboot
         and a small multiboot loader gets written
         or all the hardware autodetect needs to be removed
         from 9load
         and 9load gets reduced to being able to bootstrap kernels
         from minimum state (and become PXE compatible).
         read: 9load does too much.

vt3       I like the reduction idea.

kuroneko  more of 9load's function belongs in the kernel propper.

vt3       so basically modularize the processes.

kuroneko  that way we can carry it over to other archs when appropriate

vt3       yeah, i understand.
         another solution is to have a 9load variant for other
         archs and leave 9load as is.
+vmhobbes

uriel     vt3: no, because 9load duplicates kernel functionality
         already, that would only make matters worse

vt3       well, there's x86 and then there's everything else.

uriel     vt3: and something so tricky and black-art as ide-proving
         you only want to do in one place

kuroneko  IDE probing isn't that black-art either IMO
         the fact that linux can do it with much better certainty
         and accuracy than 9load is fairly indicative of that
         IMO

vt3       if we move off 9load, what do we break?

uriel     kuroneko: I think it's due to higher user base, ide-proving
         is very bug-sensitive to bios and chipset issues

kuroneko  vt3: any driver thats stupid enough to depend on 9load.

uriel     vt3: we "break" the install CDs not working 50% of
         the time

__20h__   Moving plan9.ini into /boot.

kuroneko  basically, the biggest problem I have with current
         9 boot practice is that it follows the 'distrust the
         preboot environment' philosophy
         which ultimately works against you in the longer term.

uriel     kuroneko: I'm not so sure of that

kuroneko  a 9 cd bootloader should lever eltorito for example.

uriel     kuroneko: preboot-environments can't be relied on from
         what I have seen

kuroneko  uriel: unfortuantely you're stuck with them.

uriel     kuroneko: yea, but the PC is a hell of a swamp of 'standards
         and bugs'

kuroneko  and preboot environments are generally sane enough
         to boot your kernel and get the real stuff going

uriel     (how long until you can't boot new PCs without doing
         ACPI? already some boards hardly work without it)

vt3       so basically moving towards something as the obsd camp
         has today.
         but with a graphical install.

uriel     kuroneko: well, yea, I agree the kernel should deal
         with things, and that the boot loader should just "do
         enough to get the kernel"

kuroneko  ACPI belongs in the kernel if its to be there at all.
         I'm already going to be working on openfirmware devicetrees
         in the kernel

uriel     kuroneko: yes, I agree...

kuroneko  so sparc wont' require hardcoded magic numbers

uriel     kuroneko: but we should make sure that the kernel doesn't
         care who gets at it(ie., as you said, that 9load does
         as little as possible)

kuroneko  well, thats the thing.

uriel     cause I fear in the end some day we will be forced
         to boot from grub or some such abomination

kuroneko  if plan9x86 starts to conform to multiboot, we can
         start heading that way
         multiboot means grub works.
         it means a number of other first-stage booters work
         and it shouldn't be hard to write a minimal bootloader
         that can boot a plan9 multiboot compatible kernel

uriel     there are some not very kind words about grub and it's
         "Unified boot standards" things in 9fans archives

kuroneko  I guess I should search the archives sometime then.

__20h__   Plan 9 doesn't do multiboot?

vt3       well, does get the kernel mean get the drivers? i think
         our model relies on drivers being in the kernel, which
         in turn requires us to get rid of floppy installs which
         don't have enough room for a grand unified kernel.
         ;)

kuroneko  20h: 9load might be multiboot, but the kernel itself
         doesn't.

uriel     http://groups.google.com/group/comp.os.plan9/msg/2b2e7752e8208afe
         (that one is a classic)

kuroneko  the whole thing about pain is simply because plan9
         is basically a major misfit on most platforms.
         it ignores abi (which is a good thing sometimes, but
         not othertimes), it ignores host configuration services,
         it ignores standard disklabels and partition tables

uriel     doing things right seems to be a major misfit on most
         things in this world :(

kuroneko  uriel: I don't call ignoring the established protocol
         for you host system 'doing things right'
         instead, I consider it 'taking the easy way out'.

uriel     http://groups.google.com/group/comp.os.plan9/msg/7f681582d17af0a2

vt3       hmm, the 9load trinity (9load, 9fat, Plan9.ini). We
         should consider retiring 9fat as well perhaps.

__20h__   You have two possibilities: plan9.ini or a writeable
         /boot.

vt3       a writable /boot seems like an interesting idea.

uriel     ACTION isn't sure writeable /boot is worth the trouble

lantis    mbrfs :) ?

uriel     9fat isn't all that bad

vt3       it isn't that good either.

__20h__   Where are problems with 9fat?

uriel     vt3: it doesn't create as much trouble as 9load...

vt3       it really seems like a quick fix in the big picture
         of things.

__20h__   So you want fossil support for Grub?

vt3       i see them as being interelated.

uriel     vt3: it might look a bit ugly, but it's simple and
         it works

kuroneko  9fat is good. its simple.
         however, 9fat's partition should be a MBR partition
         not a plan9 partition

vt3       from a security standpoint i don't trust it.

uriel     yea, how 9fat is 'hosted' is a bit... weird..
         vt3: uh? you don't trust your hardrive? then tough
         luck

__20h__   'security standpoint' - which one?

vt3       local access and lack of permissions

__20h__   So you think fossil is more secure, when you boot some
         CD with -AWP?
         For local access will you need machine guns.

kuroneko  local access is a non issue.

uriel     vt3: in Plan 9 we have real security, not delusions
         of security

kuroneko  the terminal owner can screw things over just as easily
         with fossil.
         [non-issue as in: this is not an issue to be resolved]

uriel     exactly

vt3       ok, we'll revisit it later then. :)

__20h__   But EROS boots, so you can try it. :P

kuroneko  fossil is NOT suitable for bootloading either.

uriel     oh dear, vt3 would have loved the EROS presentation
         what a load of crap it was

__20h__   But they use some sort of 9P for their network communication.

uriel     __20h__: I thought they had given up on hvaing any
         kind of network at all

kuroneko  to boot from a fossil fs you'd need a full IP stack
         and venti client so you can pull files out of venti
         if they're ont in the fossil cache.

uriel     __20h__: I even asked him about it, and he said "too
         hard"

kuroneko  that is too complicated for a bootloader.

uriel     kuroneko: yea, not worth it either, doesn't earn you
         much over 9fat

__20h__   So pbs needs to be able to start the kernel image?

kuroneko  __20h__: basically.

__20h__   It will stay at the basics.

kuroneko  the other thing I like about 9fat is it drastically
         simplifies floppy booting.
         you're basically using the same fs parsing code for
         floppies as you do for small 9fat partitions

__20h__   " /* when boot is changed to only use rc, this code
         can go away */" (/sys/src/9/pc/main.c)
         How about that way?

uriel     more russ on grub:
http://groups.google.com/group/comp.os.plan9/msg/b2463c380db1f18d

kuroneko  the whole thing is, if 9fat was an MBR partition, grub
         could be configured out of it.
         invalidating the whole configuration thing.
         and it shouldn't be too hard to teach grub how to read
         its config out of plan9 9fat partitions either.
         its just a matter of teaching grub about plan9 partition
         tables

uriel     well, to be honest, I agree with russ that I can't
         understand why a boot loader should need so much 'configuration"

kuroneko  it doesn't.
         grub requires about the same amount as 9load.

uriel     dunno, maybe it's just that the docs are a mess, but
         every time I have tried to install grub by hand, it
         has been a nightmare

kuroneko  I've installed grub many times by hand.
         then again, I probably understand certain bits about
         x86 better than a lot of people.

uriel     well, like everyhting, once you know the right dance,
         I guess it's not hard
         better than me certainly :)

kuroneko  even the first time I installed grub wasn't too painful

uriel     but I can't see why grub should need me to understand
         that stuff(and really, it has it's own set of weirdines
         and peculiarities, like it's own way to name devices
         and so on)

kuroneko  the device naming thing is a pain.

lantis    yeah

kuroneko  but its one you're stuck with everywhere.
         every preboot environment labels devices its own way

lantis    it becomes really funny when you are dealing with BSDs..
         root (hd0,0,a) or some f'..

kuroneko  lantis: blame disklabel for that.

uriel     this is interesting:
http://groups.google.com/group/comp.os.plan9/msg/61aab4e96e69764b
         seems like russ changed his mind in the end
         (or he was being cynical?)

kuroneko  openboot paths shall not be mentioned.
         they are beyond evil
         and are only made managable by labels.
         ['boot disk:a' actually maps to 'boot /devices/../../.../sd@n:a'
         or some other magic on most openfirmware systems]
         SGI ARC labels disks in its own way...
         SRM labels disks in its own way
         etc
         preboot sucks because everybody does it different.
         tough biscuits.
         you just have to live with it.
         you (hopefully) spend under 1% of your time in your
         preboot environment.
         working out the correct disk 'name' isn't too hard
         fortunately in most preboot environments.
         and usually you set and forget.

vt3       seems like a good time to start a project or fork to
         prove a point, and without bothering folks at BL. just
         be creative without the hassles.

kuroneko  Its on my to-get-back-to list.

...

uriel     we got email

vt3       cool. i'm glad Russ is reading. life is good.

kuroneko  uriel: we did?

uriel     kuroneko: yes :)

kuroneko  greylisting slows my mail influx right down

uriel     kuroneko: check your mailbox :)
         ah, I see

kuroneko  so it'll be a while before it turns up
         uriel: summary?

vt3       that was a good email.

uriel     kuroneko: 9load must diea, but it's not as bad as it
         seems ;)
         (but maybe I misread , so dont' take my word)
         kuroneko: I can paste in query if you like

vt3       unix bias? I thought it was my DOS bias. ;)

kuroneko  uriel: hrm. try it. :) I hope irssi doesn't floodprot
         by default. :)

uriel     kuroneko: are you registered in this shit netowrk?
         if you are, I can't :/

kuroneko  yeah, I am.
         been around for too long ;)

uriel     then you will have to connect to irc.oftc.net; because
         I'm not registered, and they filter out msgs from non-registered
         users to registered users

kuroneko  ah
         bloody hell. :)

uriel     kuroneko: just join #plan9 in irc.oftc.net

kuroneko  the sym53cxxx comment came from the fact that if you
         don't link in the sym53cxxx detection support into
         9load and then boot a kenfs kernel, kenfs does not
         see the 53cxxx
         [similarly, 9load also detonates violently if you have
         a 53c810, 825 or 815 without SCRIPTS support]
         somebody has updated the 53cxxx driver at some point,
         and its definately not particularly friendly now
         I'm pretty sure when I looked at the 2e 53cxxx driver,
         it wasn't dependant on SCRIPTS