Nekonomicon - mtools

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 20, 2013, 12:01 a.m...

This

http://www.gnu.org/software/mtools/

seemed like it would be useful, especially for working with SD cards ...

I sure didn't get very far though ...

Code:

  cc-1137 cc: ERROR File = mtools.h, Line = 266
  
  Unnamed prototyped parameters not allowed when body is present.
  
  int ask_confirmation(const char *, ...)  __attribute__ ((format (printf, 1, 2)));
  
  ^
  
  cc-1129 cc: ERROR File = mtools.h, Line = 266
  
  A left brace ("{") is expected at this point.
  
  int ask_confirmation(const char *, ...)  __attribute__ ((format (printf, 1, 2)));
  
  ^

While we're on the subject ... a little reading is a dangerous thing but it looks like files systems on Irix live in userland ? Which would mean that FAT16 and other file systems should not be impossible ?

_________________
lemon tree very pretty and the flower very sweet ...

ShadeOfBlue
Moderator
Who joined Nov. 25, 2003, 12:09 p.m.
and authored 726 notes

Wrote the following at April 20, 2013, 2:46 a.m...

You can delete __attribute__ and everything from it to the semicolon. In this case, it's just a hint for GCC that the function behaves like printf.

Since it deals with filesystem access, it's possible that the code uses __attribute__((packed)) or something similar for various structures. You must convert these hints into their MIPSpro equivalents (IIRC "#pragma packed" in front of the struct should work fine)

hamei wrote:

While we're on the subject ... a little reading is a dangerous thing but it looks like files systems on Irix live in userland ? Which would mean that FAT16 and other file systems should not be impossible ?

IIRC, they are actually in the kernel (it would be too slow otherwise), but each FS has its own module, so it should be relatively easy to add new ones.

One of the things on my ever-growing todo list is to port FUSE to IRIX. Then we could use practically _any_ filesystem

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 20, 2013, 4:27 a.m...

ShadeOfBlue wrote:

IIRC, they are actually in the kernel (it would be too slow otherwise), but each FS has its own module, so it should be relatively easy to add new ones.

One of the things on my ever-growing todo list is to port FUSE to IRIX. Then we could use practically _any_ filesystem

That's what I always thought too but came across this (oddly enough, while reading people gushing about fuse, which seems to be a re-animator's version of the OS/2 IFS idea - all the file systems in OS/2 were userland, so maybe not so slow after all ?

It's a pressy about Irix 6.1 but might be applicable ? (Might also be wrong, too - if you believe a press release, I have a nice bridge to sell

http://www.sgistuff.net/software/irixin ... 6.1TR.html

SGI Blurb wrote:

File Services

The IRIX file subsystem supports multiple physical filesystems of different file system types, and gives them the appearance of a single logical filesystem with a hierarchical arrangement.

IRIX 6.1 uses the Virtual File System interface, known as the vnode interface. The name vnode is derived from the name of the data structure used in the interface. This interface was developed to facilitate the incorporation of different filesystems. A de facto standard, the vnode interface is used by third-party providers of filesystem technology, as with the enhanced filesystem found in the Developer Magic Tracker product. It facilitates the inclusion of several filesystem types into IRIX 6.1, including:

XFS, our newest filesystem, discussed earlier

EFS, our high-quality incumbent file system, now supplanted by XFS

proc, which provides access to the image of each active process in the system. Both 64-bit and 32-bit /proc clients can operate and issue standard /proc ioctls. Additonal ioctls were added for 32-bit debuggers to support 64-bit clients

NFS, the mount path on the server of the directory to be served via NFS

ISO 9660, a file system type used to mount CD-ROM discs in High Sierra or ISO 9660 (with or without the Rock Ridge extensions) formats

DOS: The file system driver supports 5.25-inch floppy drives in three standard formats when used with the freestanding SCSI floppy drive. The standard single and double density dual-sided 3.5-inch drive and the 3.5-inch 20.1MB floptical drive are also supported.

swap, which can be either a file or block device to be used as a swap resource

_________________
lemon tree very pretty and the flower very sweet ...

ShadeOfBlue
Moderator
Who joined Nov. 25, 2003, 12:09 p.m.
and authored 726 notes

Wrote the following at April 20, 2013, 6 a.m...

hamei wrote:

That's what I always thought too but came across this (oddly enough, while reading people gushing about fuse, which seems to be a re-animator's version of the OS/2 IFS idea - all the file systems in OS/2 were userland, so maybe not so slow after all ?

I'm not very familiar with how OS/2's kernel worked, so it's possible they made this idea work fast enough, but on UNIXish systems, such an approach is much slower. If you look at the diagram on the wikipedia page on FUSE, you'll see that it needs to do 4 trips across the user/kernel boundary and those are relatively expensive. It's not a total deal breaker, but significant enough that you wouldn't want to have your root filesystem in userspace.

hamei wrote:

It's a pressy about Irix 6.1 but might be applicable ? (Might also be wrong, too - if you believe a press release, I have a nice bridge to sell

http://www.sgistuff.net/software/irixin ... 6.1TR.html

Oh, the VFS is entirely in-kernel

If you look inside the directories under /var/sysgen, you'll see the object files for various kernel modules that are linked together to make the final /unix kernel when you run autoconfig. Among those modules are also filesystems. By editing the accompanying files you can actually make an IRIX kernel without support for FAT or something

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 20, 2013, 6:53 a.m...

ShadeOfBlue wrote:

I'm not very familiar with how OS/2's kernel worked, so it's possible they made this idea work fast enough

Seemed plenty fast at the time but then ... a 486-66DX seemed fast then, too

http://www.edm2.com/0103/os2ifs1.html

Quote:

the object files for various kernel modules that are linked together to make the final /unix kernel when you run autoconfig. Among those modules are also filesystems. By editing the accompanying files you can actually make an IRIX kernel without support for FAT or something

Or, conceivably, if one were bright and talented enough, a FAT16 file system ? I was under the impression that we could kiss off any changes to the Irix kernel but possibly not ?

edit : Shade, you keep sending us neophytes off to the land of knowledge

There is a "umfs" User Mode File System in /var/sysgen/system/irix.sm which would seem to indicate that the same functionality that Fuse presents is already in the Irix kernel ?

I don't think I need support for HFS, either ... hmm ...

_________________
lemon tree very pretty and the flower very sweet ...

miod
Who joined Oct. 9, 2009, 1:44 a.m.
and authored 183 notes

Wrote the following at April 21, 2013, 2:18 a.m...

hamei wrote:

That's what I always thought too but came across this (oddly enough, while reading people gushing about fuse, which seems to be a re-animator's version of the OS/2 IFS idea - all the file systems in OS/2 were userland, so maybe not so slow after all ?

I'm afraid you got the wrong impression from IFS - filesystems under OS/2 were kernel code, but dynamically linked so that new filesystems could be added without too much hassle. The same goes for the device drivers - they would look like regular dll but use different entry point and are allowed to use the DevHlp services.

_________________
:Indigo:

R4000

R4400

R4400

R8000

R10000

R4000PC

R4000SC

R5000SC

R5000

RM7000

2xR10000

R12000

-

2x2xR10000 :Fuel:

R16000

among more than 150 machines : Apollo, Be, Data General, Digital, HP, IBM, MIPS before SGI , Motorola, NeXT, SGI, Solbourne, Sun...

ShadeOfBlue
Moderator
Who joined Nov. 25, 2003, 12:09 p.m.
and authored 726 notes

Wrote the following at April 21, 2013, 2:32 a.m...

hamei wrote:

http://www.edm2.com/0103/os2ifs1.html

It looks like the filesystems were in-kernel, but there was also an option to use a FUSE-like arrangement, for easier development.

hamei wrote:

Or, conceivably, if one were bright and talented enough, a FAT16 file system ? I was under the impression that we could kiss off any changes to the Irix kernel but possibly not ?

It should be fairly straightforward to implement a FAT16 filesystem module

You don't need the IRIX source code to make a new FS module, the required structures are in the publicly available headers and there should probably be some official documentation on how to do this.

It's similar to developing new device drivers for the kernel.

hamei wrote:

edit : Shade, you keep sending us neophytes off to the land of knowledge

There is a "umfs" User Mode File System in /var/sysgen/system/irix.sm which would seem to indicate that the same functionality that Fuse presents is already in the Irix kernel ?

Interesting! It doesn't seem to be documented anywhere -- perhaps it wasn't finished?

I will disassemble the module when I get some free time.

hamei wrote:

I don't think I need support for HFS, either ... hmm ...

You can also remove PPP support and some special locking implementation for Oracle databases and there's plenty more like that

I had fun commenting out stuff in that irix.sm file when making a minimal kernel for an Indy with a memory shortage. But be careful not to comment out too much, otherwise the system won't boot

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 21, 2013, 3:48 a.m...

ShadeOfBlue wrote:

It looks like the filesystems were in-kernel, but there was also an option to use a FUSE-like arrangement, for easier development.

Spent the afternoon on this :shock:

It looks to me like :

FAT is in the OS/2 kernel but the other (and more common file systems) are only partially in the kernel. I do know that if you accidentally left an IFS= statement out of config.sys, you were screwed. You could get TEDIT running from a floppy to fix it but unless you were running FAT, there was no disk access. HPFS, HPFS386, and JFS are all like this. So I guess you can say the filesystems are in the kernel but if the driver and ifs dll's (which are both external to the kernel) are not loaded, then you ain't got no filesystem.

I'm sure you and miod are correct but is it time for the "walks like a duck ..." statement ?

There are a lot of very-interesting and useful installable file systems readily available for OS/2 (and have been for twenty years, la la la la la Linux, I'm singing to you

), so if a similar capability is already in Irix, it'd be great.

MIPS processors don't have the Ring0, Ring3, etc etc junk that plagues the Intel processors, do they ? I'd do more searching but I'm araid I'd get captured by the history of the Hittite Empire or something... damned internet, too much stuff to read !

Quote:

It should be fairly straightforward to implement a FAT16 filesystem module

Best news I've heard all week, cuz natcherly I have a realworld use : CF cards larger than 2 gb.

Quote:

It's similar to developing new device drivers for the kernel.

Oh good. Good practice for adding a USB device or two

Quote:

Interesting! It doesn't seem to be documented anywhere -- perhaps it wasn't finished?

Or more likely they just never wrote any documentation ? There is other stuff in there I wasn't able to find much info on either. Must be somewhere, I am just an easily-deviated searcher ...

Quote:

You can also remove PPP support and some special locking implementation for Oracle databases and there's plenty more like that

You mind-reader you

_________________
lemon tree very pretty and the flower very sweet ...

ShadeOfBlue
Moderator
Who joined Nov. 25, 2003, 12:09 p.m.
and authored 726 notes

Wrote the following at April 21, 2013, 9:18 a.m...

hamei wrote:

MIPS processors don't have the Ring0, Ring3, etc etc junk that plagues the Intel processors, do they ?

R4k and up have three privilege levels -- kernel, user, and supervisor (but nobody actually used that one

). Two are enough to implement a secure OS.

hamei wrote:

Quote:

It should be fairly straightforward to implement a FAT16 filesystem module

Best news I've heard all week, cuz natcherly I have a realworld use : CF cards larger than 2 gb.

FAT is a really simple filesystem; making an IRIX module for it should take about a week or two. Remind me again sometime in July

hamei wrote:

Quote:

It's similar to developing new device drivers for the kernel.

Oh good. Good practice for adding a USB device or two

That's much more complicated

The current USB implementation is completely undocumented, so the cleanest thing to do would be to port the USB stack from NetBSD or something similar. This is a lot of work, since someone has to rewrite the parts dealing with announcing new devices to the kernel, making entries for them under /hw and so on.

hamei wrote:

Quote:

Interesting! It doesn't seem to be documented anywhere -- perhaps it wasn't finished?

Or more likely they just never wrote any documentation ? There is other stuff in there I wasn't able to find much info on either. Must be somewhere, I am just an easily-deviated searcher ...

A quick disassembly of the module would show if it only has stubs or actually implements something. Reverse engineering the API is probably too much work and it would be easier to just port FUSE to IRIX.

hamei wrote:

Quote:

You can also remove PPP support and some special locking implementation for Oracle databases and there's plenty more like that

You mind-reader you

Also, to speed up booting, you can put an "exit 0" after the first few lines of comments in /etc/init.d/sendmail and /etc/init.d/esp (or availmon or something...). Even if you chkconfig those off, they will still print a message and run some crap which takes some time at boot and shutdown. There are some other files like that, but I always forget what they are

canavan
Who joined July 21, 2003, 5:19 a.m.
and authored 665 notes

Wrote the following at April 21, 2013, 12:22 p.m...

Sadly, FAT16 is practically limited to 2GB. You can use 4GB partitions with a non-standard cluster size, but that doesn't work under IRIX or my Canon D40. You'll actually need FAT32 to reliably access "DOS" formatted filesystems larger than 2GB. I actually find the IRIX method of implementing userland filesystems as NFS-Servers rather interesting. If I'm not mistaken, iso9660, CD-Audio, DOS (FAT16 and FAT12 with VFAT long filename support) and hfs are implemented this way.

Aside from some kind of kernel support (either as a kernel module or via NFS Server), you'd also need a mediad plugin, like /usr/lib/devicelib/fmt_dos.so to automatically mount the filesystems. I've actually looked into making such a plugin for firewire devices. I can't quite remember the exact reason why I didn't get this to work, but it did involve in one way or another the unusual device names of firewire devices (e.g. /dev/dsk/1394/30e002e0454647/lun0vol/c3p0).

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 22, 2013, 6:27 a.m...

canavan wrote:

I actually find the IRIX method of implementing userland filesystems as NFS-Servers rather interesting. If I'm not mistaken, iso9660, CD-Audio, DOS (FAT16 and FAT12 with VFAT long filename support) and hfs are implemented this way.

Now that you mention it, I remember reading about that and it was a neat idea.

Quote:

Aside from some kind of kernel support (either as a kernel module or via NFS Server), you'd also need a mediad plugin, like /usr/lib/devicelib/fmt_dos.so to automatically mount the filesystems.

I'd be content to manually mount the card if I could get it to be twice as big

4 gig CF cards are cheap these days ... It would be fun to try formatting a larger card xfs but my camera wouldn't know what to do with it.

Meanwhile, back at the ranch, we got past ERROR one and two by deleting from the __attribute to the semicolon (thank you Shade) but now :

Code:

  cc-1515 cc: ERROR File = config.c, Line = 521
  
  A value of type "int" cannot be assigned to an entity of type "const char *".
  
  devices[cur_dev].name = strndup(img, ofsp - img);
  
  ^

_________________
lemon tree very pretty and the flower very sweet ...

duck
Who joined Oct. 27, 2003, 5:22 p.m.
and authored 363 notes

Wrote the following at April 22, 2013, 8:09 a.m...

hamei wrote:

Meanwhile, back at the ranch, we got past ERROR one and two by deleting from the __attribute to the semicolon (thank you Shade) but now :

Code:

   cc-1515 cc: ERROR File = config.c, Line = 521
   
   A value of type "int" cannot be assigned to an entity of type "const char *".
   
   devices[cur_dev].name = strndup(img, ofsp - img);
   
   ^

This looks to me like a bit of a false flag error, the problem is not that strndup returns int, it's that on IRIX it does not exist.

you can probably fudge something with strncpy like

Code:

  devices[cur_dev].name=malloc(ofsp - img);
  
  strncpy(devices[cur_dev].name, img, ofsp - img);

I'd test this if I didn't have a headache. Just doing a #define strncpy(img, size) strcpy(img) isn't likely to work because I suspect they're doing some pointer arithmetic and thus won't have a null byte to stop at. Also, using the address of a variable in size calculations gives me the heebie-jeebies.

_________________
:Octane:

halo , oct ane
N.B.: I tend to talk out of my ass. Do not take it too seriously.

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 24, 2013, 4:24 a.m...

duck wrote:

This looks to me like a bit of a false flag error, the problem is not that strndup returns int, it's that on IRIX it does not exist.

you can probably fudge something with strncpy like

Code:

   devices[cur_dev].name=malloc(ofsp - img);
   
   strncpy(devices[cur_dev].name, img, ofsp - img);

I'd test this if I didn't have a headache.

Wull, ah'll be danged, got past that and made objects all the way to where it failed to link

Thank you ...

Code:

  ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol.
  
  ld32: WARNING 84 : /usr/lib32/libsun.a is not used for resolving any symbol.
  
  ld32: ERROR   33 : Unresolved text symbol "libiconv" -- 1st referenced by charsetConv.o.
  
  Use linker option -v to see when and which objects, archives and dsos are loaded.
  
  ld32: ERROR   33 : Unresolved text symbol "libiconv_close" -- 1st referenced by charsetConv.o.
  
  Use linker option -v to see when and which objects, archives and dsos are loaded.
  
  ld32: ERROR   33 : Unresolved text symbol "libiconv_open" -- 1st referenced by charsetConv.o.
  
  Use linker option -v to see when and which objects, archives and dsos are loaded.
  
  ld32: INFO    152: Output file removed because of error.
  
  gmake: *** [mtools] Error 2

I'm not so sure this thing is going to work even if I get it to link but came this far with help from y'all, seems like it would be rude to stop now. Back to the salt mines ....

I certainly do like the idea of extending FAT file support to FAT32 tho. Mmm, even more useful than USB mass storage

_________________
lemon tree very pretty and the flower very sweet ...

duck
Who joined Oct. 27, 2003, 5:22 p.m.
and authored 363 notes

Wrote the following at April 24, 2013, 4:38 a.m...

hamei wrote:

Code:

   ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol.
   
   ld32: WARNING 84 : /usr/lib32/libsun.a is not used for resolving any symbol.
   
   ld32: ERROR   33 : Unresolved text symbol "libiconv" -- 1st referenced by charsetConv.o.
   
   Use linker option -v to see when and which objects, archives and dsos are loaded.
   
   ld32: ERROR   33 : Unresolved text symbol "libiconv_close" -- 1st referenced by charsetConv.o.
   
   Use linker option -v to see when and which objects, archives and dsos are loaded.
   
   ld32: ERROR   33 : Unresolved text symbol "libiconv_open" -- 1st referenced by charsetConv.o.
   
   Use linker option -v to see when and which objects, archives and dsos are loaded.
   
   ld32: INFO    152: Output file removed because of error.
   
   gmake: *** [mtools] Error 2

I'm not so sure this thing is going to work even if I get it to link but came this far with help from y'all, seems like it would be rude to stop now. Back to the salt mines ....

Come now, it practically yells it can't find libiconv :-P

_________________
:Octane:

halo , oct ane
N.B.: I tend to talk out of my ass. Do not take it too seriously.

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 24, 2013, 6:18 a.m...

duck wrote:

Come now, it practically yells it can't find libiconv

Three times, even

But this is a common problem that drives me batty. The linker can't find something that I can find very easily following the path that it was given. I end up screaming, "Look, you stupid shit ! It's right here, right where I told you !!"

Time to quit for now, return to the struggle tomorrow. Thanks for the kick in the butt

_________________
lemon tree very pretty and the flower very sweet ...

jpstewart
Who joined Sept. 21, 2010, 2:31 p.m.
and authored 165 notes

Wrote the following at April 24, 2013, 6:31 a.m...

hamei wrote:

But this is a common problem that drives me batty. The linker can't find something that I can find very easily following the path that it was given.

Is there an "-liconv" option somewhere in the link command? It's quite possible that the linker could find libiconv...if somebody (i.e., the Makefile) bothered to tell it to use libiconv.

(Blame it Linux-centric code/developers. The iconv functions are part of GNU libc and thus don't require an external library to be linked on a Linux box. So the Makefile may never have asked the linker to look for an external libiconv.)

_________________

Sun SPARCstation 20, Blade 2500
HP C8000

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 24, 2013, 6:46 a.m...

Oops, hit the wrong button and deleted my thanks to jp. That was the last hurdle and a worthy entry to the Compiling with MIPSPro wiki entry. It's probably there, too, I just didn't see it :oops:

thanks again, jp

_________________
lemon tree very pretty and the flower very sweet ...

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 25, 2013, 7:18 p.m...

One vote for current, can we clean out a few of these simple common libraries that everyone uses ? C'mon, collectors, just a few minutes to try out a potentially useful application or two ... the Octane needs cpr. Look through /beta and give it a chance to live, please ?

_________________
lemon tree very pretty and the flower very sweet ...

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 25, 2013, 7:32 p.m...

Been using these for ages. They seem to work. They have been in beta for two years. Someone else must be running these ?

One vote for current, please

btw, there is talk of removing irix support from these tools so if us Irrixxers don't speak up, we'll get exactly what we deserve ... hellooo out there. Squeaky wheel gets the grease and all that.

_________________
lemon tree very pretty and the flower very sweet ...

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at April 26, 2013, 6:28 a.m...

God help us all, there's an mtools 4.0.18 tardist in neko's incoming now. If it doesn't stink up his server too much it will be available for mass criticism shortly.

Unfortunately, I can't do much testing of many of its features at the moment since I don't have enough slots for the firewire card. But the binaries don't seem to blow anything up, at least.

Information on the program is here :

http://www.gnu.org/software/mtools/

lock and load ....

_________________
lemon tree very pretty and the flower very sweet ...

SGI: Development

mtools - Page 1