Good. Once you start looking at the code and understanding what it
does, it's a lot easier (and less frightening).
> When I decided to implement the filesystem driver, I originally
> wanted to just do it purely from reading the existing sources and
> documentation, without bothering anyone with questions.
Maybe one day we'll get there :-/
> However... the available documentation, although it has been
> VERY helpful, leaves me with some questions nonetheless. So as
> such, I'm looking for a fs mentor, and/or someone who can tell me
> where TFM is that I should R. ;o)
Apart from vfs.txt, I'm not aware of much other documentation. If
there are specific questions you have, please let me know and if I
know the answer, I'll update vfs.txt.
> I have read Documentation/vfs.txt (the bible), and have studied
^^^^^
<blush>
> the minix, romfs, ext2fs, and fat filesystem code. I havent dove
> deeply into it at all, but I've tried to learn what I need to do
> the job, and how the structures and methods work in the fs. I
> must say that I am amazed at the amount of design that has went
> into the vfs, and the filesystems, it is very very structured! I
> just need to understand it now. ;o)
Yep.
> The superblock structure seems to become complicated quite
> quickly when analyzing the minix sources. Lots of deeply nested
> stuff, etc... I lose track of what is going on.
Some of it you can probably ignore. Filling in the super_operations
structure is the main thing. I think some of the other fields are
updated by the generic VFS code.
> So, question number 1 is:
>
> Is there a SIMPLE filesystem implementation existing for Linux
> that may or may not be part of the official kernel? The
> filesystem I'm working on is a floppy disk based system - not
> based on any UNIX filesystems. If anything it is closer to FAT
> than anything.
Hm. When I wrote devfs I looked at procfs and ext2fs, the old vfs.txt
and the include/linux/fs.h header file.
You might also try reading the devfs source code. I think it's easy to
understand ;-)
> Secondly, is there a TEMPLATE directory of some kind that gives
> the necessary empty functions, etc for the bare minimum stuff
> that must be implemented?
Not that I've seen.
> Can anyone offer suggestions as to what to do when implementing a
> filesystem?
Copy the code for some existing filesystem (I'd suggest devfs because
it's all kept in one file) and rip out the bits specific to that
FS. You could even remove all code from within functions but leave the
operation structures and stub functions in place. Then do:
s/oldfs/myfs/
You might also want to consider making the FS name configurable using
a module option. This way each time you get an Oops when you do
something with your embryonic FS, you don't have to reboot. Just
install a new module with a new FS name. Thus you can do:
# insmod -o test1 myfs.o name=test1
# mount -t test1 /mnts/test1
# [use FS]
Oops
# [bugfix, edit, recompile]
# insmod -o test2 myfs.o name=test2
# mount -t test2 /mnts/test2
# [use FS]
and so on. Saves lots of reboots.
> Will my filesystem be available through the loopback driver? Or
> will I need to immediately implement a hardware driver for the
> real disk drive as well? (Something I plan on doing as well later
> on).
You will be able to use the loopback driver. You'll probably want to
use the ll_rw_block code to implement access to the block device.
> I've got a disk image from this drive, with a working filesystem
> on it, and that is what I want to work from. I'd like to
> implement parts of it in userland until I see I can get dir
> listings, and access files read-only. Then make it read-write,
> and offer file creation/deletion/rename/etc... THEN make it a
> kernel module, and finally integrate it into the kernel proper.
You'll then need to emulate the ll_rw_block API in userspace. And
you'll need to emulate parts of the syscall API. I'd suggest
forgetting about userspace development and write a kernel module right
from the start.
> Any help from the guru's out there would be greatly appreciated,
> and if necessary, I will tell the filesystem that I'm
> implementing, but I'd rather not yet...
I'll help with improving vfs.txt and I might even provide the start of
a template FS, in return for knowing what you're working on. I'll keep
it to myself, if you wish :-) Fair trade?
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/