On Fri, Aug 28, 2009 at 8:06 AM, Uriel<urie...@gmail.com> wrote: > On Fri, Aug 28, 2009 at 7:23 AM, ron minnich<rminn...@gmail.com> wrote: >> On Thu, Aug 27, 2009 at 6:54 PM, Federico G. >> Benavento<benave...@gmail.com> 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) are really >> 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
