From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5d375e920908280406i6dd118c1h50f5fbe1c0835a7a@mail.gmail.com> References: <32d987d50908271854u6da41079q26dc57984a2daffe@mail.gmail.com> <13426df10908272223u3c6238c8o404081a9620c6219@mail.gmail.com> <5d375e920908280406i6dd118c1h50f5fbe1c0835a7a@mail.gmail.com> Date: Fri, 28 Aug 2009 09:04:31 -0300 Message-ID: From: Iruata Souza To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] new 9atom.iso Topicbox-Message-UUID: 5995b866-ead5-11e9-9d60-3106f5b1d025 On Fri, Aug 28, 2009 at 8:06 AM, Uriel wrote: > On Fri, Aug 28, 2009 at 7:23 AM, ron minnich wrote: >> On Thu, Aug 27, 2009 at 6:54 PM, Federico G. >> Benavento wrote: >> >>> I could achieve the same as I did by doing "copy 9load E:" on windows >>> with this new approach, but I'd need to boot some linux live CD >>> and dd my way out to put the new loader there which I'll be too >>> hacky and I'd probably need a version of prepdisk for linux >>> on that live cd as well, if I got it right. >> >> yep, this is a good point. It's the same reason that Peter Anvin >> argued against using linux as a boot loader in place of grub or pxe or >> whatever. There are simple standards on booting PCs, and if you >> conform to them, you are more going to work in all cases. If you don't >> conform to them, there are more cases where you can't work. Your Vista >> example is a good case study. >> >> So the FAT partition is good when you want to interoperate. But as you >> point out, it's kind of 1/2 of a real fat partition, which means >> sometimes, even if it looks ok in vista or whatever, it's not really >> ok. It's not really possible to fit a true FAT file system handler in >> a 512 byte pbs. The Plan 9 pbs (and I assume most of them) =C2=A0are rea= lly >> a "find a file by name, get the offset, and just start loading >> contiguous data form whatever is at that offset in the partition until >> done". That's why there are things like install_grub, or lilo, or >> other such tools. If you delete and replace 9load and it ends up >> discontiguous, well, you may not be able to boot, hence the need to >> sometimes remove and replace all the files in the FAT. >> >> There are a number of reasons to like using a plan 9 kernel to boot >> your machine: drivers, native file systems, and so on. Interoperation >> with vista is not one of them. It may well be in the long term that >> the best way to remove 9load is to make Plan 9 grub-bootable. > > You try to present this as if using a Plan 9 kernel to boot somehow > precludes the use of the existing 9fat setup, this is not true, and > the whole point of the original GSoC project was precisely that: to > boot using a kernel without changing anything about 9fat and plan9.ini > so we could have a drop in replacement for 9load. > there was no 'without changing' anything. it was just to replace 9load. the project proposal was accepted without touching the 9fat subject. if it's not specified, it's open to discussion. > > And given that such a setup would have all the advantages you list > here, plus would retain the advantages people enjoy from 9fat, it is > hard to understand why doing something else is such a great idea. > this has been explained already: 9null does not care about the filesystem where the kernel lives, as long as Plan 9 knows how to mount it. if you like fat because of interoperability, that's ok, we have dossrv and 9null can use it. we simply don't require it. i don't see how fgb's solution would not work with 9null. i myself have setup a fossil disk for testing outside of the Plan 9 machine with 9null and it booted just fine. it would have been the same if i had setup a fat partition outside. iru