Chris Newport wrote: > > Sorry, I did not make myself clear. > > Linus Torvalds wrote: > >> On Fri, 25 May 2007, Chris Newport wrote: >> >> >>> Maybe we should take a hint from Solaris. >>> >> >> No. Solaris is shit. They make their decisions based on "we control >> the hardware" kind of setup. >> >> > Not really a Solaris feature. This is a feature of the Openboot PROM > which is also used by several other vendors. > The Openboot PROM knows how to write to disk. The same should > apply on Apple hardware and others which use the openboot > convention. It doesn't, though. It is not part of any specification of Open Firmware that you MUST be able to write to any exposed disk. In fact, I know of one firmware implementation (ours) where we don't allow it. Apart from being a bitch to implement safely (i.e. for people's data) it is also quite a security problem to allow the firmware interface to write to the disk. You can't make the differentiation between "at the firmware console" and "inside a booted OS" unfortunately. The 'solution' in Solaris is actually that the filesystem and disk write handling is done by the OS bootloader and not the PROM. All the PROM knows how to do is read off the bootloader (in a special partition in a special filesystem format) and execute it after probing the hardware and providing the device tree. The first stage boot loader then knows how to read UFS filesystems so it can grab the kernel and load kernel modules, and write back a kernel dump if it needs to. That, and Linux drops OF support like a lead weight very early in boot. About all you can rely on is the device tree listing all your disks present, and even then, Linux will redetect all of these with native drivers and give them new names anyway. In fact, Solaris does the same (but it is better about associating the device tree entries than Linux) -- Matt Sealey <matt@xxxxxxxxxxxxxx> Genesi, Manager, Developer Relations - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
