OSDev.org

I've been working somewhat on my Disk Image manipulation kit, 'imagetools', I wrote about earlier and I've come to a bit of a stall. I've got some ideas floating around in my head, but I'd like other's opinions on what I could do next.

• - The VFS layer needs to be worked out. It should be flexible enough to allow compiling in what would normally be a plugin while still allowing dynamic plugins as well. Also, should I manipulate images via individual file/data procedures, ala "copy file X to partition Y, directory Z"? Should I break it down to writing file streams and seeking to appropriate locations? Another way perhaps?
  - The file system support itself is a bit awkward. Should I rewrite all of the file system libraries myself? (That could get really tedious, and it also ties in with the previous item.)
  - I'm not very good at creating Makefiles, and the ugly hack I have right now is really only a stopgap measure.
  - Byte order issues...
  - Other ideas? (Might add a few later.)

There is support planned for EXT(1,3,3,4), FAT(12,16,32), VFAT, XFS, JFS, HFS(+), Reiser(3,4), and SFS in the future. I may also include BSD file systems for completeness sake, but with each new one comes a new (and slightly more complicated) required API. For instance, BSD systems use 'slices' and each of those slices have their own 'partitions', unlike most Linux file systems.

I'd appreciate any ideas, questions and/or comments you might have.

The current code is located here on repo.or.cz, and the mob branch is enabled.

/bump because it's been over a week since the previous post.

It's interesting that you plan on including support for the original ext filesystem. Does anyone actually use it anymore?

xvedejas wrote:It's interesting that you plan on including support for the original ext filesystem. Does anyone actually use it anymore?

Probably not, but it's only a plan. I'm still debating if I should have a plugin for each file system major version, or collapse each version into a single plugin. I'm thinking that the plugin system should also be able to load more than just file system support, but also the ability to support different disk image formats like VMDK, QCow, and others... not just raw disk images.

because I am extremely wanting such a library/program as this, I would be willing to help a little bit in my free time. I can help with simple coding(I'd rather not design the VFS, but if you have a design, I wouldn't mind coding initial support code) and I can try my hand at implementing the FFS filesystem when it's more complete, and also test that it can run and compile on *nix systems that aren't linux(BSDs)...

if I can help with anything, just email me at earlz - AT - earlz.biz.tm

earlz wrote:because I am extremely wanting such a library/program as this, I would be willing to help a little bit in my free time. I can help with simple coding(I'd rather not design the VFS, but if you have a design, I wouldn't mind coding initial support code) and I can try my hand at implementing the FFS filesystem when it's more complete, and also test that it can run and compile on *nix systems that aren't linux(BSDs)...

if I can help with anything, just email me at earlz - AT - earlz.biz.tm

Well, the mob branch is enabled, so you can push anonymously to the repository whenever you like. checkout as normal, but use the user name 'mob'. (It's keyless and passwordless.) However, due to the code being nowhere near the state for even an alpha release, things are bound to change drastically. This includes a set of major changes to the plugin API which should make it a little more robust.

Edit: Thanks to a 'git checkout -f master', all the said changes are gone. This is why you should never work on a master branch. Gotta pat myself on the back for that one.

Edit: Thanks to a 'git checkout -f master', all the said changes are gone. This is why you should never work on a master branch.

It's also usually why people suggest you commit often. git is especially good at this - you can make a bunch of local commits and then merge ("rebase") them into one big one when you actually (or merge back into master).

lol I'm clueless on git for right now, so I'll have to get up to speed. Your REPL looks overly complicated as well.. though, it does work on single command mode(though that isn't the REPL). I added a little test help command and it only worked in single command mode..

edit:
and your make PLATFORM=linux works for OpenBSD except for I had to remove the -Wextra, as my gcc doesn't support the flag. (and your code has a ton o' warnings lol)

earlz wrote:lol I'm clueless on git for right now, so I'll have to get up to speed. Your REPL looks overly complicated as well.. though, it does work on single command mode(though that isn't the REPL). I added a little test help command and it only worked in single command mode..

edit:
and your make PLATFORM=linux works for OpenBSD except for I had to remove the -Wextra, as my gcc doesn't support the flag. (and your code has a ton o' warnings lol)

You should add a Makefile.OpenBSD or Makefile.BSD so that you can use PLATFORM=BSD instead. Since a few hours ago I've managed to completely fuckover a week worth of local modifications that I was about to push. This is a good reason to check which terminal window is open when you run 'git checkout -f master'. (Resetting the working code to the last commit.) As I don't have a BSD machine for testing, I'd appreciate it if you could email me the results of your testing, once I've actually fixed things.

syntropy wrote:

earlz wrote:lol I'm clueless on git for right now, so I'll have to get up to speed. Your REPL looks overly complicated as well.. though, it does work on single command mode(though that isn't the REPL). I added a little test help command and it only worked in single command mode..

edit:
and your make PLATFORM=linux works for OpenBSD except for I had to remove the -Wextra, as my gcc doesn't support the flag. (and your code has a ton o' warnings lol)

You should add a Makefile.OpenBSD or Makefile.BSD so that you can use PLATFORM=BSD instead. Since a few hours ago I've managed to completely fuckover a week worth of local modifications that I was about to push. This is a good reason to check which terminal window is open when you run 'git checkout -f master'. (Resetting the working code to the last commit.) As I don't have a BSD machine for testing, I'd appreciate it if you could email me the results of your testing, once I've actually fixed things.

will do, and I'll attempt to make a new makefile.openbsd or if it works also with freebsd, then I'll just add it as .bsd... and I'll put that in the mob branch..