Detecting if an *.elf was excuted from the hard drive

[ps2ibm]

Is there any way to determine if an elf was launched from the hard drive in ULE? When i check argv[0] it always says host:[elf name]

thanks

[dlanor]

Is there any way to determine if an elf was launched from the hard drive in ULE? When i check argv[0] it always says host:[elf name]

That is because the standard method of launching an ELF from HDD with current homebrew methods is to use a pseudodevice driver called 'fakehost' which uses the 'host:' device identifier, identical to the one used by the real 'Host' interface driver.

The confusion with the real 'host:' device is intentional, as it means that a program launched this way can use the same IO calls to access the launch folder, regardless of whether the launch was made from HDD, as is normal for finished programs, or if the launch was made via LAN, which is normal during early development of a program.

Passing a real HDD path in argv[0] would cause several problems, not only because it requires other IO functions than those used for 'Host', but also because there is NO single device driver that can use a full HDD path at all !!!

That sounds shocking, I know, but it's really true. Each full HDD path has to be split into two parts. One part is used to mount the correct partition from the HDD device driver into the PFS device driver, and another part which is recombined with a PFS prefix to form the final path by which files and folders can be accessed. Passing that path in argv[0] might seem a viable alternative, but it's really not so, as the PFS link might get unmounted and need remounting, and then there's no info in argv[0] for how to do it.

Some commercial stuff (eg: Dev2 methods for mod-chips) do use the full HDD path in argv[0], but like I said before, this means that no single IO function can deal with accessing a file or folder through that path. Of course, it can be done, by splitting the path and using the parts in multiple calls like I described above, but current homebrews simply don't do that...

Another good alternative would be to create a new HDD-related driver, in addition to the current one, which would handle such path splitting and remounting automatically. Thus each reference to a path passed to that driver would imply a check for the mounted paths, with possible remounting if needed, followed by the real access using the rebuilt PFS path. However, this would still only help applications with current support, which can adapt to using the new driver. Older applications would still work as before.


I almost forgot to give you the answer for how to check for fakehost usage. It's a bit hard to describe briefly though, so you really should check it out for yourself, in the main() function inside "main.c" of any recent uLE source package.

In brief:
Check if argv[0] has "host:" as its first 5 characters, and if so, note that the launch was made either through the real Host device, or through 'fakehost'.
Use the subversion function "smod_get_mod_by_name" to check for a loaded module named "fakehost", and if that returns non-zero, then you know that this was a fakehost launch using HDD. But you still don't know the real HDD path! So you can only access it through the fakehost device, which naturally dies if you perform an IOP reset... Quite sad...

I guess I really should look into possible ways of retrieving the real path from the fakehost driver, and perhaps even rewrite it if that can't be done in its present state.

Best regards: dlanor

[ps2ibm]

That is because the standard method of launching an ELF from HDD with current homebrew methods is to use a pseudodevice driver called 'fakehost' which uses the 'host:' identifier, similar to the one used by the real 'Host' interface driver.

The confusion with the real 'host:' device is intentional, as it means that a program launched this way can use the same IO calls to access the launch folder, regardless of whether the launch was made from HDD, as is normal for finished programs, or if the launch was made via LAN, which is normal during early development of a program.

So if there was a file located in the same directory as the .elf would I be able to read that file using the standard fio functions?

Example

On the hard drive I have a partition called "files", and within that partition there is an elf file, and a configuration file

hdd0:+files/file.elf
hdd0:+files/confg.cfg

If I execute file.elf from the hard drive using ULE, then argv[0]=host:file.elf, would I be able to read the file host:config.cfg just using fioOpen, fioSeek, fioRead, etc.?

Another good alternative would be to create a new HDD-related driver, in addition to the current one, which would handle such path splitting and remounting automatically. Thus each reference to a path passed to that driver would imply a check for the mounted paths, with possible remounting if needed, followed by the real access using the rebuilt PFS path. However, this would still only help applications with current support, which can adapt to using the new driver. Older applications would still work as before.

So create a drive that would take an input as the a path on the hard drive like "hdd0:+videos/sports", and have it

1. check if the partition "+videos" is already mounted
2. mount the partition if necessary to pfs0: -> pfs9:
3. when the user wants to open a file in the sports directory the driver would already know where the partition "+videos" is mounted so it would be able to handle opening the file

[dlanor]

So if there was a file located in the same directory as the .elf would I be able to read that file using the standard fio functions?

Example

On the hard drive I have a partition called "files", and within that partition there is an elf file, and a configuration file

hdd0:+files/file.elf
hdd0:+files/confg.cfg

If I execute file.elf from the hard drive using ULE, then argv[0]=host:file.elf, would I be able to read the file host:config.cfg just using fioOpen, fioSeek, fioRead, etc.?

Yes exactly, though I wouldn't bet anything on having a full complement of functions. In fact I recommend sticking to the real basics, like the ones I've used myself, such as fioOpen, fioLseek, fioRead, fioClose. I'm not entirely sure, but it seems that even fioWrite doesn't work properly, as I can't resave a CNF by those methods.

The loading of it works fine though, using the path "host:LAUNCHELF.CNF", but saving back to the same path does NOT work, which is why we tell everyone to always use the SYS-CONF folder for configs used with uLE launched from HDD. Because that allows consistent use of the same path both for loading and saving, which doesn't work with the path in argv[0].

So create a drive that would take an input as the a path on the hard drive like "hdd0:+videos/sports", and have it

1. check if the partition "+videos" is already mounted
2. mount the partition if necessary to pfs0: -> pfs9:
3. when the user wants to open a file in the sports directory the driver would already know where the partition "+videos" is mounted so it would be able to handle opening the file

Yes, that's what I had in mind, and of course this should be a *complete* IO driver having all that the normal one offers, except that some things should be done by fioIoctl calls, so that all other calls can be kept compatible to the simpler IO drivers, allowing the 'fio' calls to be used for all devices, without resorting to explicit 'fileXio' calls.

Things that lack an equivalent 'fio' call, such as file renaming, can easily be accomplished like I did it for the 'Host' device, using a fioIoctl call instead. You can check this out if you like in "net_fsys.c" of my modified ps2host source in the uLE release package. I also plan to add a similar fioIoctl to the mass: driver eventually. I just haven't gotten around to it.

If you check out "filer.c" of the uLE sources you will find that we already use a 'generic' IO system internally, so that we can use identical function calls regardless of the device type (except for some device-unique stuff on MC for example). But this only solves some of the problems for uLE alone, and we need more system-wide solutions.

Best regards: dlanor

[ps2ibm]

I'll work on a driver, but I never did any sort of driver programming so it will most likely take a good amount of time.

When I start it I'll put the source on here
http://argon-ps2.svn.sourceforge.net/viewvc/argon-ps2/

if you want to help development let me know I can give you write access if you have a sourceforge.net account.

[user112]

@dlanor:
What do you think about passing the real HDD path as a second argument, to be used in Argon? And maybe later other "HDD-aware" applications may take advantage of that.

[dlanor]

@dlanor:
What do you think about passing the real HDD path as a second argument, to be used in Argon? And maybe later other "HDD-aware" applications may take advantage of that.

Unfortunately this method might still cause problems with existing programs, as some of them may regard the 'extra' argument as being something entirely different...

I would rather define an alternate launch method, to be used in parallel with the normal one, but only when the user specifically configures uLE to do so for a given launch button. This alternate launch method would pass the complete HDD path in argv[0], using a format similar (though not quite identical) to the format used for such path displays in uLE.

So when starting a program named "testprog.elf" in the folder "/testfold/" of the partition "+testpart", the content of argv[0] would be "hdd0:+testpart/testfold/testprog.elf". It will then be the responsibility of the launched program to break that string down into the components needed to perform the partition mounting and access the files through the PFS driver.

The advantage of using such an alternate launch method is that we can continue to use the old method for elfs that need it, while the new method is 100% compatible with the launch method used by Dev2-capable mod chips. I know for a fact that my DMS4pro uses that format, and I've seen MI users report similar results. So a program adapting to such usage should work with anything.

But please note that even a new (and as you say HDD-aware) program should still remain compatible to the old launch methods, even if some features may be limited when such a launch method is recognized, due to the inability to determine the proper home folder.

For such purposes I suggest falling back on some file being found in "mc0:/SYS-CONF/", similar to how uLE handles it, although not necessarily in the same way. One very useful variation on this method would be to allow a small path-defining file to be used there, instead of the full config file(s), which would just specify the path to be used for cases where the real launch path can't be safely detected (or when it can be, but doesn't contain any configs).

Best regards: dlanor

[user112]

Nice, but is there really any programs that can recognize that "hdd0:+testpart/testfold/testprog.elf" format?

And btw., is there any programs that look for the second argument? If not, why not proposing passing the real path as a standard?

And what do you think about standardizing storing that to some predetermined position in RAM?

Or maybe proposing some mechanism to get it from fakehost? Like opening a file with some special name?

[dlanor]

Nice, but is there really any programs that can recognize that "hdd0:+testpart/testfold/testprog.elf" format?

No, not yet AFAIK. But some such usage is the only way to pass a path that conforms with universal standards for argv usage in C programming.

And btw., is there any programs that look for the second argument?

I believe so, although the ones I use regularly do not, and I believe 'fakehost' lacks the ability to pass such arguments. But I also know that PS2Link and PS2Client have the capability of launching both ELFs and IRXs with extra arguments.

If not, why not proposing passing the real path as a standard?

Because that would violate the standards for argv usage mentioned above. And it would be needless, since the only reason for it would be to avoid some extra work in programs that need to use an HDD path passed in argv[0]. That extra work can easily be handled by a new lib function or two, which would split the passed path as needed and perform the mounting of the needed partition to a PFS mountpoint.

An additional reason to use the combined path in argv[0] alone is that others have already implemented that standard, for the Dev2 boot method of mod-chips. Do you really want to drop the potential for Dev2 compatibility ?

And what do you think about standardizing storing that to some predetermined position in RAM?

IMHO no absolute RAM location should ever be used to pass launch arguments of any kind. Perhaps I misunderstood your intention though, so please explain further if that was the case.

Or maybe proposing some mechanism to get it from fakehost? Like opening a file with some special name?

The original 'fakehost' was designed to allow programs that were not inherently HDD aware to be launched from HDD and read some basic configs from it. The very fact that we make a new standard for programs which are inherently aware of HDD usage should make further use of 'fakehost' of interest only for legacy purposes (compatibility with old stuff still in use). I certainly see no need to create a future dependency on a new module of that kind.

Best regards: dlanor

[user112]

So, are you going to implement that "hdd0:+testpart/testfold/testprog.elf" format?