From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] power pc port From: Charles Forsyth In-Reply-To: <7458b557.0308020816.304c1d0b@posting.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 4 Aug 2003 10:31:13 +0100 Topicbox-Message-UUID: 102c3cbc-eacc-11e9-9e20-41e7f4b1d025 > AFAIK, SGI isn't publicly available. The last time I tried > wrestling with SGI about it, they "poltely declined" to > approve release of the source. ... >There's a lot of proprietary hardware inside the older SGIs. >And I think you'd be hard pressed to find any documentation. the silly thing is that there are or were linux ports to several of the SGI devices that ran Plan 9 (and some others). certainly i've got a copy of such a linux where the files are dated 1998. if you've got the energy (which i suppose you might if you've got the incentive of owning the appropriate hardware) you might find an intelligent human being at SGI who will understand that if linux exists for it, it is pointless preventing release of Plan 9 source for the same hardware. unless, of course, they are particularly astute and are trying to preven the release of a readable system for that hardware. alternatively, you could use the Linux code as a guide to driving the hardware and re-port Plan 9. it will be hard in the case of l.s and mmu.c because Linux ever has had, as far as i can tell from arm and powerpc ports, a remarkably x86-based approach to MMU handling and Plan 9 takes a quite different approach, especially on the multiprocessors. it's a shame because the code in /sys/src/9/power/mmu.c is a delight: clean multiprocessor mmu handling by wielding logic (eg, carefully worked out invariants) rather than sledgehammers (eg, interprocessor traps, locks and signals). i used a variant on the bebox for that reason. that code isn't SGIs. i thought it was a good example to study in an OS class.