OSDev.org

eekee wrote: ↑Tue Jul 23, 2024 9:50 am*Can* you know the boot drive?

EDD interface/device paths have been around for about two decades, so nowadays the answer is usually yes, you can.

eekee wrote: ↑Tue Jul 23, 2024 9:50 am My Zaurus had only 2 CF-card slots for storage, fixed and removable, and the fixed one was the *secondary* drive. Whether the internal drive was /dev/hda or /dev/hdb depended on whether a removable card was inserted when Linux booted. This, and my habit of frequently changing drives around on PCs, got me into using UUIDs. Assigning drive letters or dev nodes in a fixed order would be nice, but would require special-case driver code for that particular Zaurus and would be hopeless with my hardware habits. Then there's the matter of booting laptops from external drives. I'm sure rdos is fine in its professional installations, but it wouldn't work out so well for me.

One of our platforms use a SD card storage, but the SD card device driver regards it as a fixed drive. That was a bit of an ugly solution, but since we don't have any platform with removable SD cards, it works.

Some other platforms have CF cards, but BIOS translates them to IDE or AHCI, and both the IDE and AHCI driver regard the discs as fixed even if the CF card can be physically removed.

Currently, it's only USB discs that are regarded as removable. Floppies are also regarded as removable, but they are assigned to a: and b: in the DOS/Windows world (and in RDOS).

Another issue is GPT and the EFI system partition. I assign it to drive b: on fixed drives, while on removable drives, it will be allocated to a drive. This also works because floppies are never present in systems with GPT formatted drives. This has the advantage of c: still being the first "real" partition on GPT, making GPT and MBR installations compatible. Another advantage is that installation software can probe for b: and if present, knows that boot images should be place on b: instead of on c:.

Actually, the normal boot drive is always b: on GPT and c: on MBR, so I don't need to "detect" anything.

A problem is that you cannot use the normal installation software if you have no fixed drive and use an USB drive for storage. I suppose a solution for that might be to allocate fixed drive letters for USB drives when there are no fixed drives.

So, I think you can handle this for a hobby-OS project by assuming that any removable drive will be present at boot time and then you assume it will not be removed during operation. Support for removable media is a very complex issue that I try to support in the new microkernel based filesystems. It certainly doesn't work reliably in the current production filesystems.

rdos wrote: ↑Tue Jul 23, 2024 2:53 pm So, I think you can handle this for a hobby-OS project by assuming that any removable drive will be present at boot time and then you assume it will not be removed during operation. Support for removable media is a very complex issue that I try to support in the new microkernel based filesystems. It certainly doesn't work reliably in the current production filesystems.

Possibly, yeah, especially at the hardware level. Oh, hang on... I want persistent state across reboots. I also want good network support. Both of those mean any drive may go away at any time, every drive is basically removable. Lovely!

I haven't yet finalised my VFS model, but I think I'll have paths begin with a device specifier. This is very loosely inspired by 8-bit Ataris in which disk files were Dn:filename and other devices had other letters, such as S: for the screen. They were a little arbitrary; a hard disk might be H:. My device specifiers will be longer; I'd like to use filesystem labels. UUIDs and other IDs will be an option, though UUIDs themselves are long enough to give me a headache. I'll implement aliases allowing labels to be given to filesystems and devices which don't support them, though boot would need to use the filesystem's ID. I'm not sure I want a filesystem label as the first path element in case of conflicts with other kinds of devices and maybe even URLs. There's a lot to think about, which is only to be expected when designing an entirely new path scheme.

I don't know why the concept of mounting and unmounting file systems is so alien to OS developers. You decline the unmount if any files on the FS are open, and otherwise that is it. Even if you have a Windows-like OS, that should be feasible. Especially since Windows essentially allows the very same thing: It automounts all file systems that get attached (complaining if it doesn't recognize the FS), and allows explicit unmounting by right-clicking in the file explorer and selecting "eject". And will decline the unmount if the FS is still in use by something it can't stop.

Part of the topic was when OSs find it hard to identify which device to mount. This was a real problem for a short time when Linux hardware autodetection was developing but Linux filesystems didn't have unique IDs.

Besides that, I have my issues with how some OSs handle unmounting. Declining the unmount is a very annoying system administration issue, especially on Windows and Linux for different reasons. Windows can't even show you what programs have which files open unless you enable some deep system config option which warns, "This might slow the system down." Prior to enabling that option, I had to kill apps almost at random when I wanted to unmount. Often, the offending process would turn out to be a shell which was launched in a directory on removable media. Regardless of subsequent cd commands, Windows thought it was still using that directory. Perhaps the terminal window process was.

Linux's refusal to unmount has been equally troublesome. I guess it goes back to the dreaded D state; unkillable wait for IO, which is just insane when you have a network failure. I've had my share of D-state processes when I was using NFS in Linux. It's not proper design in my opinion, or alternatively, an optimization too far since it's related to zero-copy IO if I remember right. I also had an issue with Linux refusing to remount root read-only when trying to design a simple Linux system -- so simple that an initrd would have doubled the complexity, but I guess that was a foolish project anyway.

I so much prefer Plan 9 where all unmounts succeed, it just lets future reads fail. I like that, it's a more mature approach when networks are involved.

Unmount should always succeed since the OS cannot tell the hardware that a drive cannot be removed physically because some process is using it. Failing unmount points to a poor solution to removable media handling.

My solution to unmount/physically removing a device is that cached file contents can still be used, but new reads or writes of uncached content will fail. What happens is that the OS cannot delete the FS object until every process has closed all files, but it will not be possible to access anything new. Once something new is requested, the file will get closed and the cache deleted. This solves the issue of how to handle file contents that are cached in userspace without all accesses requiring to check if the drive is still accessible.

eekee wrote: ↑Tue Jul 30, 2024 3:48 pm Linux's refusal to unmount has been equally troublesome. I guess it goes back to the dreaded D state; unkillable wait for IO, which is just insane when you have a network failure.

Yeah. The justification for the D state is that after a page fault, the program might simply not be able to continue, since the page needed to continue may contain code or critical data. And in theory all drivers have timeouts. Except Linux drivers are a mixed bag, and some just don't bother with a timeout. And while it is sensible to not deliver a signal that might be caught in this state, this is not true for SIGKILL. That's also always bothered me.

eekee wrote: ↑Tue Jul 30, 2024 3:48 pm I so much prefer Plan 9 where all unmounts succeed, it just lets future reads fail. I like that, it's a more mature approach when networks are involved.

So what do you do if a process is blocked on a page fault for the FS that's gone now? SIGSEGV?

nullplan wrote: ↑Wed Jul 31, 2024 12:51 am

eekee wrote: ↑Tue Jul 30, 2024 3:48 pm I so much prefer Plan 9 where all unmounts succeed, it just lets future reads fail. I like that, it's a more mature approach when networks are involved.

So what do you do if a process is blocked on a page fault for the FS that's gone now? SIGSEGV?

I think so. It's rather difficult to check as Plan 9, doesn't have mmap, is very lightweight and I don't have a test machine with <2GB RAM. I think I'd have it segfault with option to catch the fault.

eekee wrote: ↑Wed Aug 07, 2024 2:34 pm I think I'd have it segfault with option to catch the fault.

My immediate instinct here was to object, since the fault might have occurred as it was loading the code for the signal handler (or the stack the signal handler runs on, or some data page the signal handler accesses). But remembering Linux's "force_signal()" semantics (if the signal is blocked or ignored, it gets atomically unblocked, set to default, and then the signal is delivered) actually would make this work, so long as the signal handler is not registered with SA_NODEFER, because that way, SIGSEGV would get blocked the first time the fault handler is called, and then the second time the signal would get delivered, it just kills the process.

I've made a note to think about it, but if a process's executable file has gone away, I think I'll just kill the process rather than signal. I'm not writing a POSIX system and my signals will be a little different.