Quote:
Originally Posted by GroupInode
Well I am a beginner at UNIX and I am trying to make this project as my undergraduate project.
Now I was thinking that modifying already implemented file systems is a messy thing as you pointed out. So, I was planning to make my own file system. This file system code will only include the necessary fs_ops (File system Operations i.e. system calls) and putting the appropriate pointers in stand.h. Am I thinking right?
I read an IBM Developer Forum for FUSE which explained how to create a File System in User Space which explained something very similar.
|
Ok a bit more clarity into where you're coming from. I had already guess the "beginner at UNIX" piece, but not the undergraduate project. So I would say that it all depends on what your goals are.
When I talked about "messy", I meant that a solution that would work for all (or at least several major) filesystems would likely involving hack those FS's, which might get a little unwieldy. But if this is a school project, well, as you can probably tell, I'm a bit "old school" and I would personally just start with an implementation for UFS mostly and work with the UFS code and the vnode layer. I think an initial version could be done fairly quickly with perhaps 100-200 lines of added code -- pretty minimal impact, and most existing utilities would work fine. Another 100-200 lines added to programs like ls, find, etc, which would have to be done anyways for just about all approaches.
The fuse idea, well, I haven't had very good luck with fuse, but that is mainly dealing with the NTFS implementation and hitting it pretty hard. Nevertheless this approach would probably mean more coding, perhaps A LOT more coding, and less actual understanding of Unix internals itself. Much more learning about the fuse API of course, not so much about Unix. And I think you would end up with a "toy" rather than something that could actually be used. But if you want to do a fuse version, I would try to find an existing fuse model and modify it instead, although most of the fuse's that I have seen that would be good starting pointing seem geared toward Linux, not FreeBSD. Even with fuse, you would still need to alter stuff at the
vattr layer to bring out the new
muid/
mgid info back through
stat().
I don't think that the
syscall level is the right place to put this, for some of the reasons I mentioned. It belongs in between vnodes and specific FS's code, pretty much where mtime is also updated.
Given what I said above, since all solution I believe will need it, I suggest you start by adding the fields and code support changes to
vattr and bring it out through
stat(). You can just assign dummy uids or copy the inode owner into these fields. Then modify
ls.c to print it out. That would be a good start and you need to do it regardless of which internal solution you choose. That is, build the internal support for a modified
stat() and ls(1) and leave the filesystem mods for later.