File looper v1.0.0 for IRIX

TruHobbyist

New member
Jul 27, 2019
14
11
3
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 forums.sgi.sh) 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

backups_2days.pngfather_and_son.pnghinv_help_version.pngkernel_panics.pnglist_kfl.pnglist_ufl.pngmanpage.pngtest_list.pngtest_perl.png
 

Elf

Storybook
Feb 4, 2019
514
138
43
Interesting product; it reminds me of the odd way that IRIX supports some of its periphery filesystems, namely by running a user land NFS daemon:
IRIX implements dos, hfs, iso9660, and kfs filesystems as user mode NFS daemons. In some cases errors detected by these daemons are reported as NFS errors. Although NFS is a product option, support for these filesystem types is not dependent on the installation of NFS.
It seems to me that a similar technique could be used to provide support for a variety of filesystems, and some people are looking into this :).
Perhaps one could even couple some sort of userland NFS server to existing FUSE code, which would potentially make supporting a wide variety of filesystems on loopback mounts possible.

In any case, good work, and it is nifty to see new kernel side code being written for IRIX.
 

TruHobbyist

New member
Jul 27, 2019
14
11
3
Interesting product; it reminds me of the odd way that IRIX supports some of its periphery filesystems, namely by running a user land NFS daemon:


It seems to me that a similar technique could be used to provide support for a variety of filesystems, and some people are looking into this :).
Perhaps one could even couple some sort of userland NFS server to existing FUSE code, which would potentially make supporting a wide variety of filesystems on loopback mounts possible.

In any case, good work, and it is nifty to see new kernel side code being written for IRIX.
It was a surprise to me when I stumbled on this. I was expecting a very classical user-kernel interface to work with but that wasnt the case. Anyways, it seems surprising they had somehting similar to FUSE in IRIX since the 90's. The groundwork for a FUSE-like architecture was already there. Surprising and interesting.

Also, this means, FWIW, that those filesystems supported through this NFS client/server architecture, do not require a BLK special file to be handed to mount and thus are mounted through their CHR device special files. Very frustrating if you don't know this when mounting iso9660, msdos et. al, and think the error is on your side.


Cheers
 
  • Like
Reactions: Elf

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu