Managing devices and a device filesystem

[CloudNine]

Lo,

I'm currently working on my operating system Whitix, and I've come to the point where I need to think about how I should structure a device manager and how devices should be accessed.
I recently switched from a per drive namespace for devices (A for first floppy, / for devices), but I have decided to switch to a Unix style filesystem tree, and devices on the system will be at /Devices.

However, this poses a chicken and egg problem. How can I add the floppy device to the device filesystem if I haven't already mounted the root filesystem using it? Or should I add devices to a device filesystem and then use a Mount(Filesystem*) function instead of a Mount(StorageDevice* device,char* fsName) which I currently use.

Also, how do others manage devices and more specifically, how do you abstract block devices for use in mounting?

Thanks in advance,

CloudNine

[mystran]

The traditional "unix way" is to have the files in /dev be just names for devices, with minor and mayor numbers, which are then used to identify the device in kernel. In this model, you can have a name without having a device, and you can have a device without having a name. Chicken and egg problem doesn't exist.

One alternative is something like devfs in Linux. In this case /dev is a filesystem of it's own. It automatically has a name for each existing device, but if you want to see those names, you must first mount /dev. The kernel can still access them directly though.

The question about the "root" filesystem / in Unix is a non-issue, because the root-filesystem is mounted automatically by the kernel, before starting the first userspace process (init). Since kernel mounts it, it won't need a device file, as it can access the device directly.

Sometimes an "initrd" is used, which is basicly a ramdisk that is used as the "root" filesystem until the real root is mounted. In this case the initrd-image can contain all the modules and whatnot you need to mount the real root-filesystem.

Finally, you could have a "dummy" root filesystem (which is nothing but naming service) in kernel, and then mount a "devfs" like dynamic device naming service into that dummy-root automatically. This would really just be a ramdisk-like system that's built into the kernel.

So the filesystem is really just for giving userspace visible names for devices. Internally Unix uses those two identifies. Mayor is device class, and Minor is device instance. Or something similar.

As for mounting block-devices (and not filesystems) I think it might be better idea to mount filesystems, and keep the block-device stuff internal to a filesystem. This way you could have fully virtual filesystems without a block-device (say, linux-like /proc) and network filesystems (without bothering with network block-devices).

Personally, I'm going to have a full capability system, and hence the device managers will return capabilities for block devices, the filesystem managers will give capabilities for the filesystems when given a blockdevice (where applicable) and any naming is just a guestion of having a naming service (which filesystems obviously implement) available. Naming is not limited to real filesystems though, so you can have your personal filesystem structure if you want by just writing a new naming service. No special priviledges required for that.

[CloudNine]

Ok, I guess I wouldn't absolutely need a root filesystem just to access /dev (I would cycle through my list of mount points and select the /dev, bypassing any need for a /, correct?), but how would you keep a block device internal to the filesystem? Surely you would need to indicate which block device held the filesystem in question.

CloudNine

[mystran]

You are thinking in userspace now, aren't you? In kernel, if you have a pointer to the device object, then that is all you need to name the device. You shouldn't need /dev filesystem to use devices in kernel. The /dev filesystem (or directory, as it need not be a separate filesystem) is only needed when you want to use a block device from userspace.

As for needing the root filesystem, in Unix ever other filesystem is mounted into the root filesystem, and every process needs a current working directory, so you really can't have a process without having the root filesystem if you are following the Unix Way(tm). For this reason at least Linux can't really umount the root filesystem even when shutting down; it's just remounted as read-only, because without it even the shutdown process couldn't be running (although you COULD handle shutdown completely in kernel).

[CloudNine]

Good point, I guess I could create a Mount(Filesystem*) method to mount /dev after I add devices to it. Heh, it seems so obvious now. Thanks very much

[binutils]

Whitix is a 32-bit operating system for the Intel and AMD range of processors, licensed under the GNU GPL.
It features a C compiler (tcc), Python, assembler (nasm), text editor, shell and filesystem formatter. See the Introduction to Whitix
for more information.

[Brynet-Inc]

Whitix is a 32-bit operating system for the Intel and AMD range of processors, licensed under the GNU GPL.
It features a C compiler (tcc), Python, assembler (nasm), text editor, shell and filesystem formatter. See the Introduction to Whitix
for more information.

Why the heck did you revive this topic just to post a link to that project?

...how is it even related?

[Hangin10]

...how is it even related?

The first post of the topic is all about "Whitix", it's apparently "back" or something. Dunno why he cares about it or if he was just waiting around for something whitix to happen so he could bump the thread?
Or just found it the site and searched the board for "whitix"?
(I don't mean to be antagonistic or anything... but.. why?)

[lukem95]

Oh well... its done now. It looks like a fairly stable OS (although lack of features).

I might take a look at the ISO/source.

[xyzzy]

I got ls stuck in an infinite loop in about 10 seconds of using it, doesn't seem pretty stable to me.