OSDev.org

How would you go about writing a driver for a custom filesystem under Linux?

I'm on Windows but I hope this will help. First I laid out the basic structure of the file system. You have to have a sound understanding of your goals and what you want to pull off with your file system in the future since changing it will change many things in your operating system. I suggest you start with minimal support for files and directories and not worry about too many complicated things at first. Remember to leave room for changes later. For example, right now, each entry in my file system has the below descriptor:
Note the second to last member which is 44 DWORDs that are reserved. I am not using them but I know I will do it in the future.

Then I suggest you start with a simple disk image instead of worrying about real hardware. Then once in a while, ask others (who do have the equipments) to test your images on a real hardware. I hope you will be able to find wonderful people like Dex who are willing to do things like this

Last but not least, don't get hung up on technicality and complicated matters. Write drafts of the structure of your file system and understand its abilities and lack of abilities in various cases.

XCHG wrote:I'm on Windows but I hope this will help. First I laid out the basic structure of the file system. You have to have a sound understanding of your goals and what you want to pull off with your file system in the future since changing it will change many things in your operating system.

I think the OP's question is not how to write a file system driver for his OS, but how to write a file system driver for Linux, so he can access the file system from his OS, in Linux. Unfortunately, I have very little experience with that. That said, check out FUSE. Google is your friend in this case, as no doubt many implementations of a FUSE driver can be found.

EDIT: The FUSE page mentions many projects using FUSE.


JAL

Instead I may write a prog to work with disk images formatted to my file system.

crazygray1 wrote:Instead I may write a prog to work with disk images formatted to my file system.

This is the route I'm going actually. It lacks some power in that it's hard to write such a program to integrate with things like drag and drop files (I'm not even bothering, just run the program and choose what to do to the image). On the other hand, it is arguably much simpler to do it this way, and if the program dies it won't take the host OS down with it. A driver is much more difficult to debug anyway.

Telgin wrote:

crazygray1 wrote:Instead I may write a prog to work with disk images formatted to my file system.

This is the route I'm going actually. It lacks some power in that it's hard to write such a program to integrate with things like drag and drop files (I'm not even bothering, just run the program and choose what to do to the image). On the other hand, it is arguably much simpler to do it this way, and if the program dies it won't take the host OS down with it. A driver is much more difficult to debug anyway.

It's also more portable and easier to install.

I'm making a command line prog. Like mkisofs for ISO 9660.

FUSE is probably better than writing a new app. It has the same benefits as a disk image app except that the filesystem will be able to do the same things that all linux file systems do. Even if the driver crashes, it won't take the kernel down with it because it is running in userspace. I wrote a simple driver for a pseudo-filesystem in FUSE for SQLite and it wasn't too hard. Writing it for a custom filesystem would only be a little harder. The FUSE API is pretty easy to work with. You also don't need to implement everything, just enough to do what you want. For example, I only implemented, readdir, read, and stat at first and then worried about writing later.

iammisc wrote:FUSE is probably better than writing a new app. It has the same benefits as a disk image app except that the filesystem will be able to do the same things that all linux file systems do. Even if the driver crashes, it won't take the kernel down with it because it is running in userspace. I wrote a simple driver for a pseudo-filesystem in FUSE for SQLite and it wasn't too hard. Writing it for a custom filesystem would only be a little harder. The FUSE API is pretty easy to work with. You also don't need to implement everything, just enough to do what you want. For example, I only implemented, readdir, read, and stat at first and then worried about writing later.

FUSE only supports a handful of operating systems... It would be far easier to make a portable utility in C.

Alboin wrote:

Telgin wrote:

crazygray1 wrote:Instead I may write a prog to work with disk images formatted to my file system.

This is the route I'm going actually. It lacks some power in that it's hard to write such a program to integrate with things like drag and drop files (I'm not even bothering, just run the program and choose what to do to the image). On the other hand, it is arguably much simpler to do it this way, and if the program dies it won't take the host OS down with it. A driver is much more difficult to debug anyway.

It's also more portable and easier to install.

Yup, if it follows standards and doesn't use any APIs you can just copy and compile. Command line apps are simple to port.

Speaking of command line applications, that's probably a good way to go, and what I intend to do eventually. You could add functionality to take parameters from the command line and do things automatically, such as update a file in place. Then just whip up a shell script / batch file to replace the kernel file in the image with your just compiled version and presto, you're good to go.

Brynet-Inc wrote:FUSE only supports a handful of operating systems... It would be far easier to make a portable utility in C.

Then again, the OP specifically asked for a Linux solution.


JAL