ROMDIR filesystem in userspace
Well, I guess most people don't have a clue what this is all about.
romdirfs uses FUSE which is an impressive piece of technology:
http://en.wikipedia.org/wiki/Filesystem_in_Userspace
We could also use it for Artemis to, for example, transparently map the PS2's memory to a file in the local filesystem tree, e.g. /tmp/ps2/mem. This way, any other existing tool (hex editor, disassembler etc.) could read from and write to it without knowing anything about network communications etc. which is all handled by the virtual FS.
With it, dumping the whole EE RAM would be that easy:
What a great design...$ dd if=/tmp/ps2/mem of=dump.bin bs=1M count=32
Last edited by misfire; 07-17-2009 at 10:55:56 AM.
Umm... You say virtual file system as in, when you access a "file" it's not a real file it is a block of RAM allocated for the transactions as a file?
I was working on what I consider a virtual file system once, and how it worked was original designed to be stand alone file read / write functions that would later be implemented into the "fio" functions as a mod. It works by using custom build functions for the read / write access to read / write the data to the block of RAM. It doesn't necessarily map a drive, however I call it "RAMDrv" (RAM Drive). It does a check on the file path you are trying to access, and if it reads you are accessing the drive "ram:" then it starts reading / writing the allocated RAM block. If it reads you are accessing from any other drive, it calls the normal "fio" functions.
If I ever finish it and mod it into the "fio" functions, then it in the end can be called by the normal "fioOpen", "fioWrite", "fioClose", etc. So an example of opening a file if the mod is complete would be like so: fioOpen("ram:hello.txt", O_WRONLY | O_CREAT);
Since it hasn't been modified into the "fio" functions, it currently operates as stand alone functions (rOpenFile(); rReadFile(); rWriteFile(); rCloseFile(); ). However it still can access normal files even though it's stand alone functions (it still does the path check to see if it is to access the RAMDrv read / writes or if it needs to use normal fio read / writes).
In case your wondering why I even made it, it was because I got tired of dealing with files loaded onto RAM with array buffers (ex: u8 *buffer) and passing those as arguments through functions. I wanted to have multiple files loaded without having to constantly declare a new array for it, and be able to organize it more efficiently by being able to pass a file path/name through as the argument.
But if that isn't what you meant by virtual file system, then well at least I shared thoughts on a virtual file system I wrote...
Last edited by Gtlcpimp; 07-17-2009 at 07:33:33 PM.
Virtual file systems are abstractions of data resources. For example, you could "mount" an FTP resource, so that it can be accessed just like any other directory structure with the standard file IO functions.
Gtlcpimp, I guess you are talking about IOP device drivers. Indeed, the concepts are very similar as you also have to implement the low-level file operations like open/read/write/etc. and in the end, you get a certain level of abstraction.
FYI, a developer named yownas created a romdirfs version with basic write support: http://forums.ps2dev.org/viewtopic.php?t=12217
I also released (my) version 1.1 which is still read-only. I think that proper ROMDIR write support is very hard to accomplish, and a simple user-space tool would probably do a better job.
By the way, romdirfs now has its own online repository: http://bitbucket.org/misfire/romdirfs/
FYI, I moved romdirfs to https://github.com/misfire/romdirfs
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote
