New IFS interface (jfs.ifs, udf.ifs for example)

New IFS interface (jfs.ifs, udf.ifs for example)

Post by Lars Erdma » Sat, 06 Jan 2007 05:22:47


Sorry for posting but since Scott is around ...

Hallo,

I am investigating the effort to make FAT32.IFS provide the extensions
necessary for files > 2 GB.
Since the new IFS extensions are not documented anywhere (the API is
but the changes in the IFS interface are not) I had a look at the
OPENJFS sourcecode. By mere foresight, I unlxlited OS2KRNL to find the
names of the IFS entry points. Now this struck my eye (where otherwise
everything matched perfectly):

OS2KRNL OPENJFS.IFS REMARKS
FS_CHGFILEPTR FS_CHGFILEPTR old 16-bit EP, LONG offsets
FS32_CHGFILEPTRL FS32_CHGFILEPTRL new 32-bit EP, LONGLONG offsets
FS_CHGFILEPTRL FS32_CHGFILEPTR ?

Now what is right and what is wrong ? For FSx_NEWSIZEy it looks like this:
OS2KRNL OPENJFS.IFS
FS_NEWSIZE FS_NEWSIZE old 16-bit EP, ULONG length
FS_NEWSIZEL FS_NEWSIZEL new 16-bit EP, ULONGLONG length

My feeling is that FS_CHGFILEPTRL (analogy) would be a 16-bit EP with
LONGLONG offset (and therefore FS32_CHGFILEPTR would be unnecessary).

jfs.ifs lists FS32_CHGFILEPTR while udf.ifs lists neither
FS_CHGFILEPTRL nor FS32_CHGFILEPTR.

Can someone enlighten me ? Or is the combination of
FS_CHGFILEPTR/FS_CHGFILEPTRL (both being 16-bit entry points) as valid
as FS_CHGFILEPTR/FS32_CHGFILEPTRL (16-bit and 32-bit entry point) ?

Lars
 
 
 

New IFS interface (jfs.ifs, udf.ifs for example)

Post by Scott G » Wed, 10 Jan 2007 03:08:40


This was some spectactularly ugly hacking that went in starting around
WSeB GA to support 64 bit file sizes. My recollection, which I don't
have time (or, to be honest, inclination) to verify via code inspection,
is that the kernel will look at runtime to see what function is
supported and "do the right thing." I think you should just do whatever
JFS.IFS seems to be doing...

 
 
 

New IFS interface (jfs.ifs, udf.ifs for example)

Post by Lars Erdma » Wed, 10 Jan 2007 05:11:05

Scott G. schrieb:


Thanks for the info. As to "ugly hacking": I think it is a miracle that
the OS/2 developers even got it working, considering the fact that the
interface used to be 16-bit as well as the FSHs.
At least OPENJFS does a hell of a job to avoid any FSH routine or
devhelp that could come its way (so it can stay 32-bit all the way).
By the way: the new 32-bit linear entry point of OS2DASD.DMD (strat3
entry), is that only available with the newest incarnations of
OS2DASD.DMD (those that are called "32-bits" and that only work together
with LVM) ?
Admit it, you look back at OS/2 in wistfulness. Linux is just too easy :-)

Lars