OSDev.org

I'd like some thoughts from fellow developers. In Unix style systems, there's a root filesystem, which is just a normal filesystem, mounted during system initialization, and then typically unmounted as the last thing before a reboot (or remounted read-only to avoid unmounting it at all).

The more I think of this, the more it seems kinda silly to me...

It makes sense to have a "root filesystem" in the sense of having a root directory, and mounting other filesystems there. Even Windows internally has something like this, if I'm not complete mistaken. This could however be completely virtual, a special filesystem that only exists in memory while the system is running. That way if could provide devfs and procfs like functionality directly, with the advantage that they would be always available.

So is there any real advantage of actually having the root filesystem be a real filesystem on a disk? The only advantage I can think of, is having "init" process be a regular binary on the root filesystem, which can then be loaded from disc during startup just like any other process, but I'm not convinced this is good enough reason, especially as I'd rather avoid having Unix "init" like father-of-all process anyway.. and nothing prevents configuring the kernel to automount a certain filesystem at certain mountpoint and starting a certain process from said filesystem to take care of loading rest of the system... or even loading a special process as a multiboot module, which gets loaded as the first user process, which then issues system calls to mount the initial filesystem and whatnot..

Any thoughts?

There's a lot more in the root FS than that. You don't want to carry it all in memory.

Hi,

If you create a file or directory in the root directory (e.g. "touch /foo" or "mkdir /bar") then you'd probably want that file or directory to stay there after a reboot. To do this you'd need to mount a real file system at "/" so that entries in "/" aren't lost after a reboot.

Of course on most *nix OSs you could (probably) mount a RAM disk at "/", then use a script to create sub-directories in "/" before mounting other file systems. This is harder to automate though - you'd need to change the script and create the file or directory in the RAM disk (rather than just creating the file or directory in the root file system).


Cheers,

Brendan

Loading all that stuff into a "ramdisk" would be silly.. waist of memory..

I think the file-system hierarchy of UNIX-like systems is great..

Also some people like multiple partitions on a drive.. I've never liked making more then one on a single drive, It's never made any sense to me...having to worry about resizing.. etc..

Although I always have a slave drive in my systems..

Then again, I'm not a fan of "dual-booting" either.. pick something and stick with it.. or use virtualization if you must..

I'm not really aiming for Unix-style file organization, so the issue of populating the root directory is irrelevant. I can just have a "/system" directory which is mounted to whatever filesystem contains system files..

The point about creating files in / is an interesting point. This is ofcourse only possible for the superuser in the first place, so I'm not sure if it's such a huge issue. My actual plan wasn't even really to support creating files in such a semi-filesystem, though I never thought of it explicitly, I admit.

Point was to push the traditional /lib, /bin, /home, /root, /etc, /whatever directories at least one level deeper, under something like /system which would be a mount point for what is a traditional root filesystem, basicly leaving just /proc and /dev (autopopulated devfs like thingie) to the top level, possibly with mount points for removable devices and such..

From the user point of view, I'm possibly aiming closer to Windows like organization, where you never actually get to see the real root of the hierarchy. As it is, in modern NT the drive letters are aliases for mount-points not too unlike Unix (and one can do away with most of them by mounting everything in directories under C: if one wants to).

I still like the idea of not having a "real" filesystem as /, because that way all the real filesystem can be unmounted if necessary..

Have to think some more I guess... plus I've got other things to take care of first, anyway.

Hmm, how do you load the root-fs from disk if you dont have any root-fs to mount the filesystems and drives on? It all seems messy. It makes more sense to me that the root-fs is virtual.

In my OS, there is a global object namespace that starts at /

Everything else goes from here. I have a System directory, which holds a lot of in-memory objects, like processes, devices, timers, memory mappings, etc. I mount disks as objects off of the root directory, but they could be mounted anywhere. So my FS layout looks something like this:
etc.

Andrew275 wrote:In my OS, there is a global object namespace that starts at /

Everything else goes from here. I have a System directory, which holds a lot of in-memory objects, like processes, devices, timers, memory mappings, etc. I mount disks as objects off of the root directory, but they could be mounted anywhere. So my FS layout looks something like this:

Code: Select all

/
|---Boot Disk
|---CD-ROM
|---System
    |---Devices
    |---Processes

etc.

Windows uses the same type of system (but with a \ as it's seperator).

Yeah, I liked the whole Windows concept of the Object Manager, etc. and kept it in mind when I created my system. There are a few differences though. For one thing, Windows hides most of its namespace to programs; all they see is \GLOBAL?? if I remember correctly. My OS presents the same namespace everywhere. I also use a lot more named objects, for example, every process and thread can be found in the namespace. Which among other things means you can do stuff like this:

mystran wrote:So is there any real advantage of actually having the root filesystem be a real filesystem on a disk?

I think that the concept of the "single root" filesystem has its origins in the way computers were used in the "olden times" when Unix was conceived.

There you had a system admin responsible for everything working smoothly. Users connected via terminals and didn't have to bother that /home and /usr were on different hard drives, or even different systems. All the bother was handled by the admin, a person trained and payed for the job.

Since those times, computing has changed in some ways that makes "single root" a legacy instead of a feature, IMHO.

One point is that computers have become mainstream, meaning that "everybody" is his own administrator. Another is the advent of removable media.

Both don't really mix well with "single root". Data that was at /home/user/somedata yesterday is gone today because you removed the DVD-RAM and forgot you mounted it to that directory. You cannot write to /usr/bin because of "no space left on device", but /usr/local/bin works fine (because it's on a different partition). And so on.

"Single root", imho, tries to hide a piece of information from the user that should not be hidden - the fact that there is more than one storage device involved, and what data resides on which device.

The advantages of "single root" can IMHO very well be "simulated" using virtual devices.

Say you have /physical/dh0 and /physical/dvd on the one side, and /virtual/system (mapped to dh0) and /virtual/my_backups (the media name of the DVD-RAM currently residing in /physical/dvd) on the other. If a script refers to /virtual/my_backups, it can throw a tantrum if no DVD-RAM, or the wrong one, is currently inserted.

Andrew275 wrote:Yeah, I liked the whole Windows concept of the Object Manager, etc.

Did you ever look at unix /dev or unix /proc? They're pretty much exactly what you're describing.

Candy wrote:

Andrew275 wrote:Yeah, I liked the whole Windows concept of the Object Manager, etc.

Did you ever look at unix /dev or unix /proc? They're pretty much exactly what you're describing.

/proc yes, /dev no. If we ignore devfs hackery like Linux supports (which it's getting rid of again), /dev is a perfectly normal directory, which just happens to contain "files" which are specially marked in the file system as being "device files" and which as such specify "major" and "minor" numbers instead of having file contents.

That Desktop OS screenshot is very plan9-esque.

(Want a screenshot? "cat /dev/screen | convert2png > ~/screeny.png")

Haha.. well, I didn't want to type it out, so that was the next best thing. :p

I do have a VMWare graphics driver, but I don't use it for much yet.

Btw, as a related issue, is the best known approach to listing directories (in userspace) to simply open them (either with same or different call as files) and then issue a readdir-systemcall or something similar to get the next entry?

Can anyone think of anything better?