The troubles between stage 2 and 6 are probably realizing dirs are not files, and seeing that device and driver files are different things from data files.
Then stage 6 would be realizing that filesystems themselves just sit on device files. The directories and data files are in the device files. In truth, everything is a device file.
But then, I propose a stage 7. Because when you trace it all back, with mounts pointing to device files sitting in mounted file systems, you see that /dev is a tempfs, mounted in a tempfs, in which device files are “mounted”. The fondamental root, /, is underneath the root filesystem a tempfs too. At boot, the kernel makes a tempfs, and later overlays the rootfs mounted from the /dev mounted in the root tempfs.
Everything is a filesystem, ever,thing is mounted. The true files, device files, are mounted too. They are the mounting of a kernel module in the same way a directory - a filesystem - is a mounted kernel module.
The Linux world is a ying and yang between dir structures and mounted kernel modules. In all of this, data files, the “true files”, don’t even show up. At the end, it’s just the kernel talking to itself.
Don’t leap ahead, or you will come to a false conclusion. Write a filesystem, then write another using a completely different approach for a system without a kernel. Then run them on each others targets. Only then will your mind be clear enough to see.
Hm, I wrote a btrfs tool once that operates on an unmounted btrfs partition (so I can introduce forbidden states).
And I wrote a normal fuse-based emulated fs to fool a game into loading my custom infinite world as a save.
The old masters did not have fuse and there are more devices than your SSD. Write a log formatted filesystem for an SPI flash chip, and move your fuse-based system onto a HDD. Then the next path will be revealed.
The troubles between stage 2 and 6 are probably realizing dirs are not files, and seeing that device and driver files are different things from data files. Then stage 6 would be realizing that filesystems themselves just sit on device files. The directories and data files are in the device files. In truth, everything is a device file.
But then, I propose a stage 7. Because when you trace it all back, with mounts pointing to device files sitting in mounted file systems, you see that /dev is a tempfs, mounted in a tempfs, in which device files are “mounted”. The fondamental root, /, is underneath the root filesystem a tempfs too. At boot, the kernel makes a tempfs, and later overlays the rootfs mounted from the /dev mounted in the root tempfs.
Everything is a filesystem, ever,thing is mounted. The true files, device files, are mounted too. They are the mounting of a kernel module in the same way a directory - a filesystem - is a mounted kernel module.
The Linux world is a ying and yang between dir structures and mounted kernel modules. In all of this, data files, the “true files”, don’t even show up. At the end, it’s just the kernel talking to itself.
Don’t leap ahead, or you will come to a false conclusion. Write a filesystem, then write another using a completely different approach for a system without a kernel. Then run them on each others targets. Only then will your mind be clear enough to see.
Hm, I wrote a btrfs tool once that operates on an unmounted btrfs partition (so I can introduce forbidden states).
And I wrote a normal fuse-based emulated fs to fool a game into loading my custom infinite world as a save.
What more do I need to reach dao?
The old masters did not have fuse and there are more devices than your SSD. Write a log formatted filesystem for an SPI flash chip, and move your fuse-based system onto a HDD. Then the next path will be revealed.