Hello,
I am Halonix. I am a second year undergraduate student studying Computer Systems Engineering. I am interested in working on Haiku as part of GSoc and I want to work on “Adding write support for more filesystems“ specifically ExFat.
I have studied data structures and C++ and have also built a huffman compression system using a custom tree data structure and bit level manipulation of text files. I am currently working on a High performance limit order book in C++ using O(1) data Structures.
I am ready to learn more so can you please guide me so i can get started .
Thanks
2 Likes
Hi Halonix,
You could start with the documentation of fs_shell: File systems overview — Haiku internals documentation
This is a method where you can give specific commands to a driver from userspace, and with a file backed filesystem you can then easily test driver improvements.
1 Like
Hello, the &irst steps are setting up a development environment so you can build Haiku from source and test your changes. You can have a look at Building Haiku | Haiku Project for instructions.
Once you have that set up, you can try setting up an fs_shell for exfat (based on the documentation that nephele linked and the fs_shells that exist for other filesystems) or you can decide to test the filesystem directly in Haiku. I would say setting up an fs_shell allows for more convenient testing for the first steps, since it allows to trigger one filesystem operation at a time. Whereas when using Haiku, just listing files in a directory can trigger a lot of calls to stat() and other functions to read file metadata, things happen in parallel because the system is multitasking, there are also filesystem caches adding another layer of complexity.
Let us know if you need help setting up the environment.
1 Like
Thanks, I think Haiku isn’t really optimized for VirtualBox because it hangs when I try to clone from git. I’m going to dual boot it with windows and try again.
1 Like
Most Haiku developers use qemu. You will probably have much better luck with it.
There is not that much interest in improving virtualbox support, also because of the hostile behaviour of oracle regarding it’s products (adding hidden fees and the like)
1 Like
Ahoy @Halonix !
Welcome to Haiku Archipelago !.. 
Thank you for choosing our Be 
d project !..
… to extend your knowledge and our possibilities as well.
Best regards, 
1 Like
If it continues this way - I mean, applicants appear, one after another, to extend FS availability on Haiku - this way soon we will have an FS access heaven ! 
Of course, if those all tends to merged as well –
(Sorry for seemingly overreacting, I just expressed my truly wondering what just happens here in this GSoC 2026 period !.. Seems something really happens in this Fiery Horse Year – applicants fired up to extend Haiku capabilities !… 
)
2 Likes
For the record, VirtualBox has seen updates that kinda broke smooth working for Haiku (in my experience running it in Windows), hence I use VMWare Pro for some years with pretty good results.
Yeah , I tried to use Qemu but setting up shared clipboard is not going great. Gonna try Vmware now
I love AQemu, a frontend for Qemu which deals with the complicated tech details for you. But yeah, I, too, never succeeded in clipboard or file exchange between VM and host system. Apart from that, AQemu is great.
So I have set up the build environment but I haven’t figured out how to make an exfat_shell using jam.
jam “exfat_shell”
Starting build of type regular …
Asked for bios_ia32 target boot platform
Unknown path to handle adding to image
Asked for pxe_ia32 target boot platform
Unknown path to handle adding to image
don’t know how to make exfat_shell
…patience…
…found 1 target(s)…
…can’t find 1 target(s)…
Do we need to add our own buildShell in the jamfile for exfat. I am still trying to figure it out so any help is appreciated.
Hello,
There isn’t yet an fs_shell defined for exfat. So you will have to create one. Start by having a look at Making sure you're not a bot! where the fs_shell lives. You can see there are directories for each supported filesystem. You can start adding one for exfat there, modelling it after one of the others. Ufs2 can serve as a reference, as it is quite simple.
The general idea is to build the same source code, but using special includes from the fs_shell support code. Usually this means making sure to not use the “real” system headers directly. Typically this is achieved by moving all system includes to a separate system_dependencies.h file. There will also be some preprocessor defines configured in the jamfile, that can be used in the filesystem code whenever something has to be done slightly differently. See USER and FS_SHELL defines. The first one is also used in another case, when building a filesystem as an userlandfs add-on.
I see this information is not yet present in the documentation, I’ll have a look at adding it there.
1 Like
Thanks, that clears things up. I’ll start working on it.
Hello,
I have been trying to implement the fs_shell for exfat but I am running into some problems.
1:
C++ objects/haiku_host/x86_64/release/tests/add-ons/kernel/file_systems/exfat/exfat_shell/kernel_interface.o
../src/add-ons/kernel/file_systems/exfat/kernel_interface.cpp:17:10: fatal error: util/AutoLock.h: No such file or directory
17 | #include <util/AutoLock.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
Jam can’t find the file normally. So when I add the search path to the jamfile , It finds it but then it gives me the following error.
C++ objects/haiku_host/x86_64/release/tests/add-ons/kernel/file_systems/exfat/exfat_shell/Volume.o
In file included from ../src/add-ons/kernel/file_systems/exfat/Volume.cpp:22:
../headers/private/kernel/util/AutoLock.h:15:10: fatal error: interrupts.h: No such file or directory
15 | #include <interrupts.h>
| ^~~~~~~~~~~~~~
compilation terminated.
Auto lock also doesn’t have an fssh version as I have searched the fs_shell directory ,so I can’t move it into system_dependencies .
2:
The second error is a little more frustrating. The fssh_api_wrapper and fssh_atomic are colliding so basically every function is conflicted. This is just one of many:
../headers/private/fs_shell/fssh_api_wrapper.h:65:41: error: ‘int32_t fssh_atomic_get(int32_t*)’ was declared ‘extern’ and later ‘static’ [-fpermissive]
65 | #define atomic_get fssh_atomic_get
| ^~~~~~~~~~~~~~~
../headers/private/fs_shell/fssh_atomic.h:25:9: note: previous declaration of ‘int32_t fssh_atomic_get(int32_t*)’
25 | int32_t fssh_atomic_get(int32_t *value);
| ^~~~~~~~~~~~~~~
It is probably due to the line in the jamfile that includes the private headers of fs_shell. removing that line will cause Jam to not find the api_wrapper.
I have tried redoing it multiple times but I end up at these same errors.If you could give me a hint as to why this is happening ,that would make things easier.I wanted to complete the implementation of the exfat_shell for the first patch but it looks improbable now.
Also, I want to start writing the proposal so could you please guide me as to what I should focus on.
Hello,
It will be easier to help you if you send your work-in-progress patch to Gerrit. Then we could try by ourselves and see if we can figure it out 
util/AutoLock.h is replaced by headers/private/fs_shell/fssh_lock.h which defines an alternative version of MutexLocker.h.
If you look at the system_dependencies.h file for BFS, you will see that util/AutoLock.h has been moved to a #ifndef FS_SHELL block, so that it is not used when building with fs_shell.
This means you have included fssh_api_wrapper.h before system headers.
If you look at fssh_api_wrapper.h it does this:
After that, anything that uses “atomic_get” will be redirected to “fssh_atomic_get”. That will also include any declaration of atomic_get. So, if you have a #include of fssh_api_wrapper.h and then later on an include of SupportDefs.h (directly or inrirectly), the declaration of atomic_get in SupportDefs.h will be renamed to fssh_atomic_get, and will conflict with the replacement provided by fs_shell.
This means you have to be very careful about including all needed system headers first, and fs_shell_api_wrapper after all of them. And that’s why usually all these headers are all moved into a single system_dependencies.h header, so at least you only need to solve that problem once, and have all other files in the filesystem driver just include system_dependencies.h, knowing that it will include all the other things in the right order.
1 Like
Thanks for the feedback.
[Edited] I have submitted the patch to Gerrit . The Id is 10476.
I hope we can fix this soon.
Hello, I have fixed the autolock issue and submitted a patch but its still incomplete and not really formatted correctly . The shell still doesn’t build as is. Should I keep trying to fix the issue or start researching and writing the gsoc proposal . Will this patch be sufficient to serve as a first patch or will I have to submit something else?
You should also write your GSoC proposal. The patch is also meant to help you explore the code, get to know it and see the kind of challenges ahead.
I hadn’t had time to review your patch more closely yet, I will try to have a look during the week.