Basically, there used to be a "leapfrog" design in the file driver stack, where the VFS would leap the file system entirely in favor of using the device driver itself.
Upon reflection, a few things became clear:
- The VFS, or virtual file system, should almost definitely only operate with file systems, and the way we do that is through file system drivers. If it was the virtual device system, maybe this leapfrog would make sense.
- Expanding a file is impossible with the leapfrog design, as well as a lot of other things like caching then flushing.
So, all the sort of "meta" drivers (Lensor domain sockets, pipes, etc) that used to be implemented as device drivers are now file system drivers.
Driving this change is the lack of an ability to "discover" anything on LensorOS; if you don't know an exact path, you don't know how to do anything. In hopes of implementing a basic ls, I needed a way to get directory data, and that sparked this whole line of changes.
Basically, there used to be a "leapfrog" design in the file driver stack, where the VFS would leap the file system entirely in favor of using the device driver itself.
Upon reflection, a few things became clear:
1. The VFS, or *virtual file system*, should almost definitely only operate with file systems, and the way we do that is through file system drivers. If it was the virtual device system, maybe this leapfrog would make sense.
2. Expanding a file is impossible with the leapfrog design, as well as a lot of other things like caching then flushing.
So, all the sort of "meta" drivers (Lensor domain sockets, pipes, etc) that used to be implemented as device drivers are now file system drivers.
Driving this change is the lack of an ability to "discover" anything on LensorOS; if you don't know an exact path, you don't know how to do anything. In hopes of implementing a basic `ls`, I needed a way to get directory data, and that sparked this whole line of changes.