OSDev.org

I'm looking for everyone's opinions of different filesystem layout models, and what's used in hobby OSes.

Currently, I'm using a model where all system-provided files are in '/Acess' (ala C:\WINDOWS), and user files would end up in '/Users' and '/Mount' used for general purpose mountpoints.

The first basic model I think everyone knows about is the windows/dos style root with mountpoints only (C:\,D:\,...) and the OS stored on one partition and the path to the OS files stored in the bootloader (however, later versions of windows aren't that simple, as can be seen with moving windows installs between volumes)

Second is the Unix/ model (see http://www.pathname.com/fhs/pub/fhs-2.3.pdf for the implimentation used by Linux). In this model the system (what would be in C:\WINDOWS) is now spread in across different folders in the root (/bin,/usr,...). At first glance this is very messy, but reading the linked PDF shows the logic of this system - it simplifies deduplication. Readonly/read-write, local/sharable are all in different folders, and can easily be different partitions or even be network mounts.

(Reason for this post - I'm considering changing up my filesystem layout, and wondering how to easily support shell scripts without having /bin or /usr/bin exist)

RDOS doesn't have any folders for itself. The reason for this is that it uses static linking (no need for shared libraries), and also does not implement the syscall API with shared libraries. There is no /dev folder where devices can be opened as files (IOCTL is also not supported). There is no script file(s) that configures the kernel. Instead, the configuration is centralized to a single cfg-file which describes the modules loaded (and possibly parameters), which is used to build a binary image (the configuration file doesn't need to be in the target system). Default environment variable settings can be defined in the cfg-file.

Therefore, it is enough to have a single binary image (rdos.bin) in the system, and there is no need for anything else.

RDOS can also preload files (and applications) on the z:\ drive. These files are defined in the cfg-file, and added to the binary image file.

Also consider the Mac OS X/NeXTStep/OpenStep directory structure.

There are several "roots". Each contains the following directories:

• Applications, which contains applications (and is aggregated into the global app list by the UI)
• Library, which contains applciation support files (e.g. dynamic libraries under Library/Frameworks, plugins under Library/Plugins, configuration files under Library/Properties)

There are three "roots":

• /System, which contains operating system files
• /, which includes system wide files
• ~, which contains user files (duh)

Home directories by default exist at /Users/$USER/.

My VFS natively supports local root mount points (any directories of any storage devices captured by some FS can be attached to them; there is only one requirement: such directories cannot cross each other). For example:

//root/programs - physical location is hda1:programs;
//root/settings - physical location is hda2:users/user1/settings;
//root/mydata - physical location is hda2:users/user1/data;
//root/hda1 - incorrect if reference the root directory of hda1 because index of this directory was used in root point "programs";
//root/mypics - incorrect if reference hda2:users/user1/data/pics because index of "data" is the index of root point "mydata".

It's possible to get access to the root directory of boot device through pseudo remote root "//boot" but only before taskman will run shell.

I described the model used by tyndur here:

File system and paths
The paths used in tyndur are somewhat different from other OSes, so they are probably worth a section. As you can see in "file:/apps/sh" paths do not only consist of a directory and a file name like in Unix, but also contain a third part for the service which provides the file (and therefore there are three types of paths: A relative path looks like "../apps/sh", a service-relative one like "/apps/sh" and an absolute path like "file:/apps/sh"). So far you can compare it to DOS drive letters.

However, a typical tyndur path is a combination of multiple such paths: While ext2:/ is missing something (well, which device at all?), ata:/ata00_p0|ext2:/ gives all the information needed (oh yes, the ext2 filesystem on the ata:/ata00_p0 partition). You can even nest it deeper, for example the Live CD uses "ata:/cdrom|iso9660:/hd.img|ramoverlay:/cached|ext2:/" - the CD contains an iso9660 file system which contains an ext2 image, and there is a ramdisk in between to allow temporary write accesses to the ext2 image.

There is a service file which provides aliases to avoid such tedious paths. You can look up the mappings on the service terminal.

If you want my advice: Don't try this at home, kids!

Kevin wrote:I described the model used by tyndur here:

File system and paths
The paths used in tyndur are somewhat different from other OSes, so they are probably worth a section. As you can see in "file:/apps/sh" paths do not only consist of a directory and a file name like in Unix, but also contain a third part for the service which provides the file (and therefore there are three types of paths: A relative path looks like "../apps/sh", a service-relative one like "/apps/sh" and an absolute path like "file:/apps/sh"). So far you can compare it to DOS drive letters.

However, a typical tyndur path is a combination of multiple such paths: While ext2:/ is missing something (well, which device at all?), ata:/ata00_p0|ext2:/ gives all the information needed (oh yes, the ext2 filesystem on the ata:/ata00_p0 partition). You can even nest it deeper, for example the Live CD uses "ata:/cdrom|iso9660:/hd.img|ramoverlay:/cached|ext2:/" - the CD contains an iso9660 file system which contains an ext2 image, and there is a ramdisk in between to allow temporary write accesses to the ext2 image.

There is a service file which provides aliases to avoid such tedious paths. You can look up the mappings on the service terminal.

If you want my advice: Don't try this at home, kids!

That ends up looking a lot like the monikers used by Microsoft's COM. For example, a reference to a cell in a spreadsheet in a zip file might end up looking like "/path/to/file.zip!sheet.xls!A!1". There they avoid the need to mention what handler is relevant at each stage by making it implicit, however (I.e. it looks up the handler for .zip, the zip handler looks up the handler for .xls, and so on and so forth)