I found out, to my dismay, that the CMS FS driver lacks needed functionality for 'mount -o loop' to work. What I mean is that you cannot at this time have an EXT2 FS image on a CMS minidisk and mount that with "-o loop". You can *copy* the FS image file to another filesystem, so I know it's not a matter of corrupted content.
Learning ... learning ... It turns out that "-o loop" requires a different function in the VFS layer than those which CMS FS already supports. [sigh] So! What I have found thus far is that we need at least one of the "address space" functions, and clearly "readpage" is getting called. But the effect is a locked-up 'mount' command or worse: CMSFS: cmsfs_file_open(): opening file 'lxasetup.ext2fs' inode 507 CMSFS: cmsfs_readpage(0x02E54380,0x00302DEC) illegal operation: 0001 CPU: 0 Tainted: P Process loop0 (pid: 821, task: 0079a000, ksp: 0079be20) Krnl PSW : 07082000 80000002 Krnl GPRS: ffffffff 00000000 002a3514 00000000 ... rest deleted for brevity ... Loopback mounts create a kernel process to handle the mapping of the "file" to a pseudo block device, so the "loop0" above is correct, and it does in fact have a PID like a user space process. I just don't know what [loopx] does behind the scenes. Where can I find the operation of loopback mounts outlined? It's not clear from kernel source nor from the Documentation directory. -- R;
