FUSE filesystem?

[zap8600]

Hi. My name is Zane. I'm developing a system called Cotton Candy OS. I'm trying to add a FUSE filesystem, but i don't know how to implement the fuse protocol. My OS is based on this tutorial: https://github.com/cfenollosa/os-tutorial. I have been researching for about a month now. If someone could help me that would be great.
P.S. I also need disk read/write

[Octocontrabass]

I'm trying to add a FUSE filesystem, but i don't know how to implement the fuse protocol.

Are you trying to implement a library that provides the libfuse API, or are you trying to implement the FUSE kernel API so you can port libfuse to your OS?

My OS is based on this tutorial:

Be careful, most OS development tutorials are written by beginners, and beginners make mistakes.

P.S. I also need disk read/write

You can always start with a virtual disk in memory, if you don't want to write device drivers yet. You'll probably need a VFS at some point, too.

[zap8600]

Hi. Thanks for replying. I'm guessing that I would've been trying to implement the FUSE kernel API because I wanted it to write to the filesystem. Now as I think about it, that doesn't make much sense. I have been aware about the tutorial. If I were to add a VFS, would I need some disk r/w drivers? If so, then could I get a tutorial or something similar about adding one? That would be much appreciated.

[Octocontrabass]

If I were to add a VFS, would I need some disk r/w drivers?

You wouldn't need them, but you would probably want them. (Unless your goal is to write an OS that exclusively uses network filesystems or something like that.)

If so, then could I get a tutorial or something similar about adding one?

There are no tutorials for most things in OS development. We do have a lot of information about different types of storage hardware, though. Whatever hardware you chose to support first, you'll probably need to enumerate PCI to find it, so that's a good starting point.

[zap8600]

Hi. Thanks for responding. I don't really plan on using network filesystems. The first device I will probably support would be either the easiest or a USB. The reason why I would pick a USB is because I don't really find a lot of people wanting to use it. Sure, some people will want to check it out, but I don't thinks they would actually use it. I might need information on HDDs so that I can emulate my OS in QEMU because I only have a Raspberry Pi to run my code on. I would much appreciate information about devices, inodes (for the VFS), and devices. That would be much appreciated.

[BigBuda]

Hi. Thanks for responding. I don't really plan on using network filesystems. The first device I will probably support would be either the easiest or a USB. The reason why I would pick a USB is because I don't really find a lot of people wanting to use it. Sure, some people will want to check it out, but I don't thinks they would actually use it. I might need information on HDDs so that I can emulate my OS in QEMU because I only have a Raspberry Pi to run my code on. I would much appreciate information about devices, inodes (for the VFS), and devices. That would be much appreciated.

Because supporting a USB drive would imply working USB drivers and the disk access layer on top of that, maybe start with a regular and easily emulated drive like a SATA drive to mature your disk access skills and code before doing something that has more layers and, consequentially, greater probability of introducing bugs and other mistakes? Just a suggestion.

[Octocontrabass]

The first device I will probably support would be either the easiest or a USB.

The easiest to get working well enough that you can read and write the disk would be PCI IDE. If you want something you can quickly put together to use in QEMU, that's the way to go. (It gets less easy when you start looking at things like DMA or detecting whether a drive is attached.)

I wouldn't recommend starting with USB. I mean, you definitely could if you want to, but it's a lot more work when you have to figure out how to write a driver along the way.

[zap8600]

Hi. Thanks for all your help! Sorry if I don't understand all of the information. I am in middle school, and my programming is far more advanced than what my school teaches. I'll probably need some help, as my C skills aren't that great. Thanks for all the help!

[nexos]

I'll probably need some help, as my C skills aren't that great

I would recommend getting the book "C Programming" by Sams Teach Yourself. Excellent book that describes C. If you're looking for somewhat of a challenge, you can also pick up Brian Kerninghan and Dennis Ritchie's 1989 C book.

[zap8600]

Hi. I have been reading the OSDev Wiki page on PCI IDE Controllers, and while reading through it, I noticed a couple of things. First, it requires an IRQ. My OS currently only has 2 IRQs; the timer (IRQ0) and the keyboard (IRQ1). Second, the code is a little different on this. If I could get some help, that would be much appreciated.
P.S If you need to look at my code, you can look at the tutorial I linked in my first post.

[Octocontrabass]

First, it requires an IRQ.

It doesn't require an IRQ. It's a good idea to use an IRQ, but you can poll the drive status if you don't want to use the IRQ. The wiki page you're looking at might assume you're already familiar with legacy IDE. Take a look at other pages in this category. (This is one part of the wiki that could really use some reorganization, but unfortunately that takes time I don't have.)

Second, the code is a little different on this.

What do you mean?

[zap8600]

Hi. Thanks for the response. What I meant was that some of the functions (such as outb an inb) are coded differently than mine.

[Octocontrabass]

The code on the wiki is only an example. You're not supposed to copy it into your kernel, you're supposed to read it to understand how you could write your own code.

[zap8600]

Hi. That is what I've been doing. I just thought that since my code is different, I would have to take what I understand and change it a lot.

[zap8600]

Hi. So back to what I made this forum for...

Now that I've thought about it more, I think I have an idea on making my own filesystem. What I originally wanted to do was implement the FUSE protocol into my kernel so that I could create inodes for files and directories on the disk and read, create, write, and etc. without needing to write really advanced code. Now I see that it's more complicated than I thought. What I could do is make a disk image, make a FUSE driver, open the image with the driver, make a file, close the image, and open the image in a hex editor. Then I could look at the file and, if I ever get disk access working, implement my own way to read files. If there is a way to make files with inodes without needing disk access, I would like to know. That would be much appreciated.