3 ms·

This brings up an interesting issue in OS design, and that is: What are the responsibilities of the OS's Kernel if/when all files are deleted, and all processe

This brings up an interesting issue in OS design, and that is: What are the responsibilities of the OS's Kernel if/when all files are deleted, and all processes are similarly deleted? In other words, the worst-case of all worst-case scenarios. Under that scenario, philosophically, OS-design-wise, what are the responsibilties of the kernel? Well, we might start by designing our future OS with a tiny shell inside of the kernel, for emergency use only. Also, we might consider using a file system that doesn't actually delete files when they're deleted, but rather flags the disk space as "empty" -- for future recycling. Between these two things, if they were implemented, we'd get a lot of leverage to resurrect a dead system, but there's more to this than that. You see, the above scenario should become an active unit test (tested at each recompilation) of that future OS. Also -- we want to know the fewest number of steps necessary (given the above scenario) to fix everything back to normal. In other words, a very interesting topic for future OS designers to think about!

tremon 6y ago
Under that scenario, philosophically, OS-design-wise, what are the responsibilties of the kernel? Practically speaking, none. The responsibility of the kernel (in Linux terms, but I think it's the same across all Unixen) is to start the init system (PID 1), and that's where it ends. Should PID 1 ever terminate, the kernel is in an undefined state. The VFS semantics ensure that even when the init binary is removed from the filesystem, it is not actually unlinked until its reference count is zero -- and since the kernel holds a reference to it, the kernel and init are "safe" from harm through deletion. Well, we might start by designing our future OS with a tiny shell inside of the kernel, for emergency use only. While not in-kernel, systemd is ahead of you, as it offers a shutdown-time ramfs to use as root filesystem so the real root filesystem can be safely unmounted. Previously, Linux didn't really unmount the root filesystem (it couldn't, because the kernel still had an open handle to the init binary), but mounted it read-only before shutdown. we might consider using a file system that doesn't actually delete files when they're deleted, but rather flags the disk space as "empty" This is already the case. "removing" a file in Unix only removes its name from the directory listing, the inode isn't reused until it's been cleared. And even when it's been cleared, only the inode entry is zeroed -- not the data contents. That's why tools like "shred" exist -- to make sure a file's contents are removed along with the file. a very interesting topic for future OS designers to think about I think transactional filesystems, snapshots, and log filesystems already do most of what you're asking for.
- peter_d_sherman 6y ago
  Hi Tremon, first of all, your response is interesting, valuable, and it taught me some things I didn't previously know, that is the stuff about PID 1, etc. So, I appreciate that! Also, I have no question that you are a smart person. But, that being said, I'm going to play Devil's Advocate a little bit here, if that's OK with you, as I don't think that people learn anything from agreeing with one another; but rather by the friendly and polite challenging of one another! OK, so with that in mind, here we go: >"Should PID 1 ever terminate, the kernel is in an undefined state." Undefined by WHO? If there's nobody that takes the responsibility for defining something, then there is no rule, law, custom, or precedent there, and all of those things may now be implemented as seen fit by one or more implementing parties. If that's the case -- then why can't it be implemented differently, why can't that be changed in the future? >While not in-kernel, systemd is ahead of you That might be true -- but I am NOT a member of the systemd religion! (You know, like you have Christians, Muslims, Buddhists, Hindus, Jews, and a smattering of other smaller groups in that bunch, like Wiccans, Scientologists, Deep Staters, and people that follow Joel Osteen! <g> Well, you have all of those, AND you have the people that believe in systemd! Of which I am not one of! <g>) On a serious note however, systemd, while it might create a whole lot of "conveniences" -- creates equal-and-oppositely many drawbacks in terms of code complexity and the ability for someone even moderately technical to understand what's really going on on their system. But, all of that is a "religious debate" -- of which we've already seen too many of on the Net... >This is already the case. "removing" a file in Unix only removes... Yes, this is well known... However, let's say we get a future OS student up to speed by building their own operating sysem... if they're building their own OS, then their file system will probably not do this. It a separate consideration and it adds to the complexity of the file system. On the one hand, yes, you're quite right, such a student could just take pre-made source code for a filesystem and link it to their OS, but if they did that, then odds are they'd learn nothing of value... >I think transactional filesystems, snapshots, and log filesystems already do most of what you're asking for. I don't question this. But, if you took the world's most technologically complex airliner, whether that's a Boeing 747, an Airbus A-380, or what-have-you... most people would rather fly on one of these things than even attempt to build their own plane, even if their own plane would be simple and crude by comparison, even if their own plane would be many future iterations removed from the current state-of-the-art... Well, even if someone attempted something like this and failed(!) (e.g., they tried to build the equivalent of a Wright Flyer -- the first heavier-than-air plane built by the Wright Brothers) -- well, that is far, far superior educationally (in my opinion!) to someone who uses the latest and greatest technological marvel of the world -- and, yet, doesn't completely understand it... You might say that that's my religion...<g> It's the same thing with Operating Systems... >I think transactional filesystems, snapshots, and log filesystems already do most of what you're asking for. I completely agree that they might... But you know, we might agree that Windows 10 does most of what 99% of computer users want -- so why use any Unix derived variant? I completely agree that you're right; however, Windows 10 probably does most of what you're looking for OS-wise... yet you seem to be more inclined to use a Unix derrived OS... Why? ?

tremon 6y ago

Under that scenario, philosophically, OS-design-wise, what are the responsibilties of the kernel? Practically speaking, none. The responsibility of the kernel (in Linux terms, but I think it's the same across all Unixen) is to start the init system (PID 1), and that's where it ends. Should PID 1 ever terminate, the kernel is in an undefined state. The VFS semantics ensure that even when the init binary is removed from the filesystem, it is not actually unlinked until its reference count is zero -- and since the kernel holds a reference to it, the kernel and init are "safe" from harm through deletion. Well, we might start by designing our future OS with a tiny shell inside of the kernel, for emergency use only. While not in-kernel, systemd is ahead of you, as it offers a shutdown-time ramfs to use as root filesystem so the real root filesystem can be safely unmounted. Previously, Linux didn't really unmount the root filesystem (it couldn't, because the kernel still had an open handle to the init binary), but mounted it read-only before shutdown. we might consider using a file system that doesn't actually delete files when they're deleted, but rather flags the disk space as "empty" This is already the case. "removing" a file in Unix only removes its name from the directory listing, the inode isn't reused until it's been cleared. And even when it's been cleared, only the inode entry is zeroed -- not the data contents. That's why tools like "shred" exist -- to make sure a file's contents are removed along with the file. a very interesting topic for future OS designers to think about I think transactional filesystems, snapshots, and log filesystems already do most of what you're asking for.

peter_d_sherman 6y ago
Hi Tremon, first of all, your response is interesting, valuable, and it taught me some things I didn't previously know, that is the stuff about PID 1, etc. So, I appreciate that! Also, I have no question that you are a smart person. But, that being said, I'm going to play Devil's Advocate a little bit here, if that's OK with you, as I don't think that people learn anything from agreeing with one another; but rather by the friendly and polite challenging of one another! OK, so with that in mind, here we go: >"Should PID 1 ever terminate, the kernel is in an undefined state." Undefined by WHO? If there's nobody that takes the responsibility for defining something, then there is no rule, law, custom, or precedent there, and all of those things may now be implemented as seen fit by one or more implementing parties. If that's the case -- then why can't it be implemented differently, why can't that be changed in the future? >While not in-kernel, systemd is ahead of you That might be true -- but I am NOT a member of the systemd religion! (You know, like you have Christians, Muslims, Buddhists, Hindus, Jews, and a smattering of other smaller groups in that bunch, like Wiccans, Scientologists, Deep Staters, and people that follow Joel Osteen! <g> Well, you have all of those, AND you have the people that believe in systemd! Of which I am not one of! <g>) On a serious note however, systemd, while it might create a whole lot of "conveniences" -- creates equal-and-oppositely many drawbacks in terms of code complexity and the ability for someone even moderately technical to understand what's really going on on their system. But, all of that is a "religious debate" -- of which we've already seen too many of on the Net... >This is already the case. "removing" a file in Unix only removes... Yes, this is well known... However, let's say we get a future OS student up to speed by building their own operating sysem... if they're building their own OS, then their file system will probably not do this. It a separate consideration and it adds to the complexity of the file system. On the one hand, yes, you're quite right, such a student could just take pre-made source code for a filesystem and link it to their OS, but if they did that, then odds are they'd learn nothing of value... >I think transactional filesystems, snapshots, and log filesystems already do most of what you're asking for. I don't question this. But, if you took the world's most technologically complex airliner, whether that's a Boeing 747, an Airbus A-380, or what-have-you... most people would rather fly on one of these things than even attempt to build their own plane, even if their own plane would be simple and crude by comparison, even if their own plane would be many future iterations removed from the current state-of-the-art... Well, even if someone attempted something like this and failed(!) (e.g., they tried to build the equivalent of a Wright Flyer -- the first heavier-than-air plane built by the Wright Brothers) -- well, that is far, far superior educationally (in my opinion!) to someone who uses the latest and greatest technological marvel of the world -- and, yet, doesn't completely understand it... You might say that that's my religion...<g> It's the same thing with Operating Systems... >I think transactional filesystems, snapshots, and log filesystems already do most of what you're asking for. I completely agree that they might... But you know, we might agree that Windows 10 does most of what 99% of computer users want -- so why use any Unix derived variant? I completely agree that you're right; however, Windows 10 probably does most of what you're looking for OS-wise... yet you seem to be more inclined to use a Unix derrived OS... Why? ?