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
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
