search

minexew / templeos-loader

User-space loader for TempleOS
4 stars 6 forks source link

COMPILER and STARTOS paths should be with respect to *host* file system #6

Closed minexew closed 4 years ago

minexew commented 4 years ago

Currently these paths are specified with respect to VFS. This is quite confusing (since on the command line, kernel path is specified with regards to the host file system)

The compiler binary and StartOS are loaded through FileRead, and without modifying the compiler we cannot change this (at least for StartOS). Therefore we might have to generate some sort of magical path (e.g. "$COMPILER.BIN") that will be returned to VKernel from HostGetEnv("COMPILER") and later recognized by vsyscall_handler(VSYSCALL_FGET) invoked from HostFsFileRead, which will bypass VFS entirely and use native fopen() to read the file.

Fortunately, this hack does not need to include CFile functions.

tos11 commented 4 years ago

I think this should be abandoned in favor of doing something like STARTOS="D:/StartOS.HC" using the multiple drives feature I've added with these pull requests:

https://github.com/minexew/Shrine-v6/pull/1 https://github.com/minexew/templeos-loader/pull/12

using this PhysFS: https://github.com/ljward10/physfslt-3.0.2/tree/feature/MultiLite

It seems to work for me. Please let me know if it works ok on your end.

We should now be able to make the C drive contain a stock Temple OS, Temple OS (U), Shrine, etc rootfs and keep the other VKernel related stuff and HolyC files we want to run with it on the D drive. This should allow us to build any distro from files on C without having to remove VKernel related stuff and allow us to keep them separate.

minexew commented 4 years ago

Very good. Eventually, I think we can abandon the "rootfs" / "vfs" terminology and just call the drives what they are - C and D. (keeping HostFS as the name of the corresponding FS type in the kernel)