[TruHobbyist]

Hi there!

I thought it was a good idea to give some details about the development of this. One never knows who could get motivated into developing for these platforms.

All in all, it was immense fun to work on this platform. And of course to learn something new every single day I sat down in front of it.

Every problem makes you grow in experience but, the best of all, you have to find workarounds yourself! There's not much you can do if something is not well documented other than diving deep into the problem. I had a couple of very hard to solve errors because there was simply no documentation about some interfaces. On other occasions, interface documentation was not accurate (I'm talking here about manpages, not internet).

Well, I have attached some images for you to get an overall view into the 'viscera' of this product.

The overall structure was very simple:

- user level: user command
- kernel level: kernel module


Both levels were tested individually, as well as together at the same time. I preferred a transparent model with regards to error handling:

Every error possible, is passed back from the kernel to the user level, where it is processed for user's convenience (most of them were very kernel specific). Errors are not simply wrapped up N:1 and just given out on screen as generic errors:

For example: if one function could fail because of kernel memory exhaustion, invalid user input (checked in kernel) and a missing kernel ressource at time of invokation, it is not done with an error like "kernel internal error" and there you go user, but with a singular error message that would be meaningful to the user.

This approach alone accounted for 77 return codes, which, of course, had to be tested individually.

And since we are at it: tests were done using a perl script, test.pl, that had to be coded test by test, manually. If you ever had been doing software development you know how tedious this can become. Furthermore, tests are one of the most ingrate programming subjects I know of: you need a lot of time to get one working but a single line of code that is changed in the application renders the whole test useless and you have to start from scratch again. So, if I can give you an advice: do tests at the very end and modularize every test source code you can.

The reason to choose perl was because it is extremely versatile, supports unix very well and has an unbeatable text processing capability thanks to its regexps that makes working with it much more efficient than with other languages or tools.

Maybe some words for those interested in multiplatform development: this product was first written on Tru64 (you can read about it in that forum on irixnet.org) and later on ported to IRIX. Even being both commercial UNIXES (UNICES?) I would say that, grosso modo, ~50% of the code had to be rewritten. It surprised me, but in fact, similarities start *and* end often in the name of a driver entry point (take ioctl() as an example). From there, you are in a whole new world.

My lesson learned from this project is: create portable libraries and stick to them as much as you can. This will make your life way easier!


And well, I hope you are still alive after reading this. Kudos for getting down here. Enjoy the screenshots and see you!

Tru

[Raion]

I'm not surprised Tru64, being OSF/Mach based, was very different.

Not that you should, but I'm curious how closely the kernel APIs for IRIX match HP-UX and Solaris, specifically Solaris 8 (Which is very similar to IRIX userland-wise).

[Shiunbird]

Raion, the book I'm using to learn, Advanced Programming in the UNIX environment, covers a lot all the differences. I have the Third Version, and it is so cool that it even covers modems and serial comms very thoroughly.
I have a modem at home waiting to be installed, that I will add to my rack as means of remote access in case I'm away, my two ISPs are down and there's no way else to get in. (I carry a Jornada 720 with me during long journeys, and it has a modem)

I couldn't recommend the book enough. It is a great read even if you are not a programmer or trying to learn.

I plan to get for Christmas the second edition - it is from the 90s, so it should cover more extensively IRIX and HP-UX. The Third Edition uses a lot of macos, Linux and solaris as reference and mentions others mostly en passant.

TruHobbist, do you write using your SGI and cross build? I've been using SoftBench on HP-UX. I fell in love with it. Plus the C8000 is waaaaaay quieter than the Octane. I tend to use remote X when I'm using Cosmo - it's the application I use the SGI mostly for at the moment.

[TruHobbyist]

I'm not surprised Tru64, being OSF/Mach based, was very different.

Not that you should, but I'm curious how closely the kernel APIs for IRIX match HP-UX and Solaris, specifically Solaris 8 (Which is very similar to IRIX userland-wise).

From what I've seen so far, the UNIX that's most 'alien' is, actually, IRIX. The kernel interfaces not even match the same names as on other BSD or SYSV derived systems. Some don't have equivalent functionality (take namei() vs lookupname(), for example) and others are absent totally on other UNIXES.

Similarities are the name of the 'technologies' like NFS, VFS, RPC, DDI, ... and they all come mainly from Sun. This was the case on Tru64 and is also the case on IRIX. It's the implementation where they radically differ. IRIX is no different here. For example: mknod is a user command, a library call, a syscall and, normally (!), implemented as an vnode operation in the kernel. Go look for mknod in documentation for all unixes. On IRIX you won't find this kernel interface.

The upside to this is that IRIX uses a much newer and cleaner codebase.


The userland is a different story though. Because the interfaces are very similar on that side of the OS across all UNIX.

---

TruHobbist, do you write using your SGI and cross build? I've been using SoftBench on HP-UX. I fell in love with it. Plus the C8000 is waaaaaay quieter than the Octane. I tend to use remote X when I'm using Cosmo - it's the application I use the SGI mostly for at the moment.

Oh my gosh, a C8000... One day I will own one myself. That day I will be very happy.

All my coding is done on my SGI O2, and for now, the code has to be moved from one machine to the next when attempting to port it to another machine/architecture. I'm working on a solution for that.

[Shiunbird]

=)))

The C8000 is a lovely machine. However, it's frustrating not to be able to run older graphics software. The FireGL breaks compatibility with everything else HP has done before.
And hey, you can run fully patched and up-to-date Linux if that's your cup of tea, besides the lack of graphics acceleration that no one has ever managed to fix.

There are some new old stock on eBay I think still. This is how I got mine. (Europe)

[Raion]

The file looper source code will be released shortly publicly under a dual MIT/GPL2 license. Me and TruHobbyist have brokered a deal and it's currently being sealed by me. For all of the patrons who have helped contribute over the last year I thank you as your money has been put towards this effort.

From hereon, once the replacement gallery software is finished we will be focusing heavily on IRIX development projects with your funds.

[Shiunbird]

Wonderful update! Thank you!