It cost SUN millions of dollars to open source Solaris. In lawyers, and to rewrite code it didn't own but licensed from 3rd parties.No crowd funding campaign is ever going to raise that kind of money, and there's simply no business case either when the target audience is a bunch of sentimental hobbyists.

Fortunately, the innovative (at the time) parts of IRIX, like XFS, have been open sourced ages ago.

To accentuate the special identity of the IRIS 4D/70, Silicon Graphics' designers selected a new color palette. The machine's coating blends dark grey, raspberry and beige colors into a pleasing harmony. (IRIS 4D/70 Superworkstation Technical Report)

I had the impression that all of SGI's assets, including discontinued software products, like IRIX, remained with HPE's Enterprise group. Is that incorrect? Note that other commercial operating systems, like HP-UX and NonStop remain with HPE.

I haven't looked in a while but there are (or were) torrents available that claimed to be the IRIX source code. I never grabbed one because I assumed they were either fake or jailbait (remembering what the FBI did to Chris Toshok). In addition to the XFS source code that JJ mentioned, basically all of the IRIX multiprocessor code has been integrated into Linux, in fact it's that code that drove Linux to dominance of the Top-500.

Project:Temporarily lost at sea...Plan:World domination! Or something...

I'd be surprised if a bunch of the ex-sgi guys didn't have their own copies too. Anyway, as has often been stated what would really be useful would be the source code to MIPSPro, so we could add the stuff it needs that prevents us from compiling all this so-called modrun software...

Project:Temporarily lost at sea...Plan:World domination! Or something...

vishnu wrote:I haven't looked in a while but there are (or were) torrents available that claimed to be the IRIX source code. I never grabbed one because I assumed they were either fake or jailbait (remembering what the FBI did to Chris Toshok). In addition to the XFS source code that JJ mentioned, basically all of the IRIX multiprocessor code has been integrated into Linux, in fact it's that code that drove Linux to dominance of the Top-500.

If you dig around in old Linux kernel releases, like 2.4.18 and 2.5.70, you'll find buried under arch/ia64/*, a *lot* of code that is very "verbose" and the coding style and formatting completely different from the rest of the code in Linux. I suspect this is raw IRIX code lifted from the IP27 and IP35 stuff and ported to the IA64 architecture for the bringup of the Altix product line. Of particular note in these old releases is all of the "pcibr" code that I stare at randomly in vain hopes to divine how their BRIDGE hardware worked so I can make the MIPS side work better.

There is, strangely, a very noticeable split in how SGI ported all of that code to IA64, but virtually ignores any existing code for their platforms under arch/mips/*. This leads to a lot of code duplication in Linux (mostly in header files now), so it's going to be interesting when I get around to sending patches in to unify some of it.

Even in the current Linux kernel source, you have drivers like drivers/char/mspec.c, which support the MSPEC address features of current IA64 SN2 hardware. It's on my long TODO list to see if it's possible for this driver to work on older HUB chips, like that in SN0 (IP27) and maybe SN1 (IP35), since the newer hardware is effectively an updated iteration of older hardware.

So IMHO, other than the older MIPS hardware support in IRIX, Linux appears to already have most of the good bits from IRIX. Chances of getting that old code released are likely slim-to-none. But maybe HPE would be open to releasing hardware documentation for the various system ASICS and address space layouts that could be used to develop new code.

Of interest, Micro Focus also owns all that is left of Novell, including everything NetWare. I was excited a few weeks ago to discover that they still keep all of the old NetWare TIDs online, although some have new TID numbers that require a bit of searching. Throw on top still being able to download old NW patches, and Micro Focus seems like a nice company. If they really do have any control over other OS code, like that of IRIX, they might be open to releasing some stuff about it. Likely documentation only, but that would be better than nothing.

Kumba wrote:If you dig around in old Linux kernel releases, like 2.4.18 and 2.5.70, you'll find buried under arch/ia64/*, a *lot* of code that is very "verbose" and the coding style and formatting completely different from the rest of the code in Linux.

Kumba wrote:If you dig around in old Linux kernel releases, like 2.4.18 and 2.5.70, you'll find buried under arch/ia64/*, a *lot* of code that is very "verbose" and the coding style and formatting completely different from the rest of the code in Linux.

Don't you mean 2.5.69? Most of the SN2 code got removed in 2.5.70.

I'll have to double-check. I think I was last looking at the pcibr code that SGI pulled in, and that's still in 2.5.70. SN2 code still is present through out the current kernel (like in the mspec driver, it explicitly checks for the presence of SN2).

You guys are awesome! I've submitted exactly one patch to the Linux kernel, to the hwmon code to fix a call to a deprecated function. Extremely trivial patch that worked perfectly, it removed the call to the deprecated function and replaced it with a call to the function that replaced the deprecated one, but the hwmon maintainers rejected it. I deleted their rejection email but I remember the first sentence was "Thanks but no thanks." This was a submission to the 4.10.0 kernel tree. As of today, at 4.14-rc5, the call to the deprecated function is still in there. Basically sums up everything that's wrong with the kernel development process, which is to say; everything.

EDIT: And another thing that's just killin' me; all the at-microsoft-dot-com email addresses that are now showing up in the kernel changelogs...

Project:Temporarily lost at sea...Plan:World domination! Or something...

vishnu wrote:You guys are awesome! I've submitted exactly one patch to the Linux kernel, to the hwmon code to fix a call to a deprecated function. Extremely trivial patch that worked perfectly, it removed the call to the deprecated function and replaced it with a call to the function that replaced the deprecated one, but the hwmon maintainers rejected it. I deleted their rejection email but I remember the first sentence was "Thanks but no thanks." This was a submission to the 4.10.0 kernel tree. As of today, at 4.14-rc5, the call to the deprecated function is still in there. Basically sums up everything that's wrong with the kernel development process, which is to say; everything.

You might have to dig into the history on why it was deprecated in the first place. Sometimes, you can find insight on why something was done that isn't immediately apparent. I recently went looking for an explanation for specific changes in Linux/MIPS' "atomic.h" header for the old R10000 ll/sc "WAR" bug, and ultimately discovered the explanation in a 7-year old git commit that had only a commit message but no file changes (I don't think git even allows that anymore). Knowing context and/or history can make sure you craft the patch or its justification just right.

That said, I recently tried sending in a basic "cleanup" patch for the existing IOC3 driver for Linux/MIPS and got torched by the networking subsystem maintainer himself, davem,for the patch trying to do too many things at once. So at some point, I'll have to spend a dull weekend splitting the patch up into discrete pieces, which is sometimes more of a chore w/ git than one might think (though, I am probably using git wrong).

vishnu wrote:EDIT: And another thing that's just killin' me; all the at-microsoft-dot-com email addresses that are now showing up in the kernel changelogs... :lol:

Yeah, Microsoft's newest strategy lately has been a return to the classic "embrace, extend, assimilate". We'll see about that third point, but the fact that they have a kernel-mode layer in Win10 to emulate a Linux/POSIX environment is a curious development.