From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sun, 4 Dec 2005 11:00:59 -0500 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Replacing 9load In-Reply-To: <20051204044833.GD9700@server4.lensbuddy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051204044833.GD9700@server4.lensbuddy.com> Topicbox-Message-UUID: b790f32c-ead0-11e9-9d60-3106f5b1d025 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