mounting a drive to a data file
mounting a drive to a data file
Hi,
I've searched for a while but haven't found what I need, maybe someone has an answer...
What I'd like to do is mount a virtual drive pointing to a data file (in iso-like format). I need this so I can "pack" my external files for my homebrews in a transparent way: I could then use c++ streams, and oslib load functions, and everything I wrote until now without caring where the file is really stored.
For example, I'd like to pack some images in an iso-like file "images.dat" and mount that file as a drive lets say "vfs0:/". I counld then use oslLoadImageFilePng("vfs0:/image1.png", ...) transparently. I really only need read access.
I'm pretty sure it is possible since we have iso loaders isn't it?
Thanks for anyone who can lead me to a clue.
I've searched for a while but haven't found what I need, maybe someone has an answer...
What I'd like to do is mount a virtual drive pointing to a data file (in iso-like format). I need this so I can "pack" my external files for my homebrews in a transparent way: I could then use c++ streams, and oslib load functions, and everything I wrote until now without caring where the file is really stored.
For example, I'd like to pack some images in an iso-like file "images.dat" and mount that file as a drive lets say "vfs0:/". I counld then use oslLoadImageFilePng("vfs0:/image1.png", ...) transparently. I really only need read access.
I'm pretty sure it is possible since we have iso loaders isn't it?
Thanks for anyone who can lead me to a clue.
You'll find PhysFS here:
http://forums.ps2dev.org/viewtopic.php?t=9120
That's about the closest you'll come to what you want.
http://forums.ps2dev.org/viewtopic.php?t=9120
That's about the closest you'll come to what you want.
Thanks for your answers.
That is the reason I thought about a virtual drive. With this, no need to modify any code I already wrote or OSLib, it will be totally transparent, I'd just need to use the special drive instead of ms0:/.
Jean, as I said maybe I'm totally wrong for the zip library as I never used it, I'll take a look.
So does somebody know how I can do what I want? Or have other ideas?
If you know how to do it by only writing down a couple of paths and configuration strings I'd really like to see your explanation.jean wrote:I don't really know how to do it, but i feel that adding virtual drives overhead only to avoid writing down a couple of paths and configuration strings doesn't look like a good programming practice...
I never used the zip library, and I will look at it, but I'm pretty sure it's like every other library like "PhysFS" (thanks J.F. but that's not what I need I think): you have to make calls to an API to get pointers to usually a special FILE structure/class containing your data. And that is what I want to avoid. The thing is, I already wrote many many things (really a LOT), and also I'm using oslib. If I want to be able to use libraries like those, I would have to integrate it at every place where I'm loading files in my actual code, and even in OSLib's code, which would be stupide because I'm using OSLib to avoid dealing with low levels things.jean wrote:if you want your homebrew in a well looking packed form, why don't you use the zip library?
That is the reason I thought about a virtual drive. With this, no need to modify any code I already wrote or OSLib, it will be totally transparent, I'd just need to use the special drive instead of ms0:/.
Jean, as I said maybe I'm totally wrong for the zip library as I never used it, I'll take a look.
So does somebody know how I can do what I want? Or have other ideas?
You just have to implement a filesystem driver using sceIoAddDrv, look at pspiofilemgr_kernel.h, and psplink usbhostfs as an example of a filesystem driver. You don't have to implement every function, just the ones your virtual filesystem will alow (e.g you can skip things you won't use like IoIoctl, IoDevctl, or IoWrite if the filesystem will be read-only).
Just be sure to call sceKernelExtendKernelStack in each driver function (or at least the ones in which you will call some sceIo* funcs) or you will end with a kernel stack overflow.
Just be sure to call sceKernelExtendKernelStack in each driver function (or at least the ones in which you will call some sceIo* funcs) or you will end with a kernel stack overflow.