RAMFS uses kernel memory manager to get/release memory, but this is impossible for memory above 4Gb.
And another reason - i'm planning to add boot from this disk - like Veit's memdisk do.
Having worked with this a bit more, I think that FAT will do the job. I am not so sure that FAT32 has any advantage, other than being able to use more than 2 GB of memory. Since the disk is only temporary, one would not want to be storing modifiable data files, that need to be saved permanently, on it anyway, although there may be reasons to load it up at boot time, with often used programs, or static data. FAT32 also has the problem of being slow, although with memory as the media, it should be okay. I am pretty sure that OS/2 could not boot from FAT32, because the driver is not loaded in time.
About sysview & keyboard
It does appear that UEFI does something bad. SysView is much more consistent on the T510 (no UEFI), while it works sometimes on the L530. It would be good to add "help text", at the bottom of the screen, suggesting that F10 will enable the menu. The "Alt-X" text is grayed out, and doesn't seem to work when the program initially starts.
But found more funny thing yesterday. FAT32 trap D, so disable FAT32 formatting of ram disk temporary, until investigate....
That is likely to be a flaw in the FAT32 IFS, or more likely in the FAT32 cache. I find that FAT32 is much more reliable, and faster, when I REM the CACHEF32.EXE line in CONFIG.SYS. Using it with a memory disk, and cache, doesn't make a lot of sense anyway. That could also be true for FAT.
And another reason - i'm planning to add boot from this disk - like Veit's memdisk do.
Interesting thought. Of course, it would need to be in FAT format.
RAMFS uses kernel memory manager to get/release memory, but this is impossible for memory above 4Gb.
Not "impossible", just difficult. You would need to implement a new memory manager to mange memory above 4 GB, and make a new API, or expand on a current API, to access it. That memory would not be usable in the normal way, but it could be used by programs specifically written, or modified, to use it. You have the tools to access the memory, you just need a buffer in "real" memory to allow normal program access to the data, and a way to track the memory allocation. Basically, it would be a new memory pool, for private data, outside of the normal 512 meg that is available. That would be a partial cure for the "shared memory" problem.
Sounds great, and if you get it working with the latest ACPI driver form David i will give it a try.
It may be worth your time to try it anyway. It is not difficult to switch back to normal operation. Just set it up with the new OS2LDR, REM the ACPI stuff (add OS2APIC.PSD, for SMP support), and try it. To go back, put the original OS2LDR back, and enable ACPI (disable OS2APIC, if used). Leaving the new support in the root of the drive, is a little messy, but not harmful. Be sure to have an alternate boot system, so you can put it back to normal, if it won't boot.