[Raion]

So I was doing research into the mount, mkfs etc. commands and when I hit ldd on them, one name kept recurring. libdisk.so. 

So from what my research has come about, libdisk is an SGI-internal library. It exposes many kernel level operations regarding mounts, filesystems/disk ops to the main userspace tools like mount/umount and mkfs/fx. 

One interesting thing. No package installs headers for libdisk. There's no documentation on libdisk I can find either. So I got together with my colleague who was responsible for helping with OpenFAM, and we decided to tackle it. 

Currently our scope of this is to expose every function that's being used, and we have multiple ways to determine this -- nm symbol tables for the lib and the commands linking against it, as well as any structs being used. 

I am not doing the actual "dirty" work, like before. I am hacking up a header and we're seeing if it actually works after we try each function. Of course, we'll need an actual command with source code to try it, so that's an eventuality once we go from here. 

http://gitea.irixce.org/Raion/libdisk-header

For your viewing benefit. If anyone wants to offer advice or ways to test these functions, by all means, but for now this is just me and my colleague hacking to figure it out.

[weblacky]

So far this seems high-level info, however I'd like to see how complete it really is. I keep finding Irix broken for things are aren't technically a hard drive. Like it really doesn't know the underlying specs.

So I'd suggest testing the "device info" part of the code on Floppy/floptical/ZIP/DVD-RAM and and SCSI converters you can. Also Opticals ROMs (CD/DVD) for block size info.

You may find it actually doesn't know or put erroneous values in for some of these elements for these devices.

While this isn't directly related it irks me that Irix can put FAT16 on a floppy/ZIP..but not a fixed drive! Lots of freezing with formatRMedia as well for DVD-RAM.

[Raion]

Well I can explain some of this.

I think IRIX's non HDD support is based around the SCSI standard of a 512-sector HDD, everything else is strange.

Additionally, it uses userspace NFS daemons in older versions of IRIX, with only newer versions actually having any kind of real kernel FAT support. It's all janky, and the libdisk.so primarily assumes XFS/EFS volumes, you can verify this looking at the protos I'm producing from it.

An eventual RE of the library may come in handy, but for now that's not the goal. Without a header, you or I can't use it. My goal is to make it easier to forge ahead for most of this, and while a lot of this is hacked together, it should become sufficiently polished at some point. As it stands, I have a limited understanding of all the structs/functions and am guessing a fair bit. Some things will not work right off the bat.

[Raion]

A lot of this is going faster than me or my colleague anticipated, but we are going to end up having to verify the values of these integers in some of these structs. Our functions, at least to those used by mount(1) and similar class commands, are about 60% done I think.

A large part of this is determining what's an internal and external function. You don't always know, and we're often left scratching our heads. But it has been easier than expected. The names have a pattern, and we can usually figure out their return types and such based on that.

[02girl]

Nice work!

[Raion]

It's pretty easy to discover a pattern here. I will admit that I'm not used to typing single line comments with the C89 style but for system headers I'm not taking any chances.

Thankfully a lot of structures enumerated by this library are incredibly simple and easy to figure out correspondence for where they're going and therefore confirm types and such.

I would say that this has given me a lot more confidence when it comes to understanding underlying libraries and how they operate however I know that I have a lot to learn before I'm anywhere near an avatar of this stuff LOL.

[Raion]

I've not had time to work on this in recent weeks, but I will return to it soonish.

[Raion]

I believe that everything that I need here to make a simple mount command is contained in the header. I am picking up my old Mount code over the next couple of days and I will be reviewing it and seeing how it compiles as I expand it. Again it's probably at first not going to be a one-to-one replacement, as the mount command for IRIX contains a LOT of NFS code (based on what libraries it links to and uses for function calls)
which at this time I have no interest in making work because of my lack of understanding of how that works quite yet. It should be good enough however for eventually bringing in code not only from File Looper, but other drivers that would be nice (e.g. EXT2, FAT32, maybe even NTFS or F2FS (FAT64 aka ExFAT is still patented iirc))

I also began looking with my RE friend Endeavour at some other small libraries and commands. I'm aware of some of this isn't say, reverse engineering a graphics driver but everything is integral into working up to that. I certainly don't know the first thing about the DMA or other memory aspects of even simple graphics drivers.

[Raion]

I'm excited to announce that with a working mount(1) command in preproduction (source not available yet) I have decided to RE with my old partner the entirety of libdisk. Thus far, it's given me some interesting discoveries:

IRIX supports PC Card stuff.

The library has been rewritten at least twice and contains new and old functions that basically do the same thing, other than block size limitations.

It's also giving me a better understanding of how the IRIX device tree is setup and to say the least, it's not as primitive as one would expect from System V.

[Raion]

The library's main functions are about 30-40% RE'd. The benefit here is that IRIX compiled everything with -g, making function names, variables and arguments, defines etc. all right there.

The resultant library will be released once I can verify it'll drop-in and work properly for IRIX 6.5.22,