🚀 go-pugleaf

In comp.unix.questions Jeffrey Siegal <jbs@quiotix.com> wrote:
: Steve Mading wrote:
:> : This is not quite correct.  You can start a single user program from the
:> : kernel command line with init=.  That could  be enough for some systems.
:> 
:> Alright, then switching from programs to other files, would that
:> one userland process function very well without any of the
:> libraries in /lib, without the ability to interface with with
:> system routines because the library to interface with the kernel
:> is not there?  How well will the system function without all the
:> config files in /etc?  (for example, will the kernel allow this
:> "init=" program to run when there is no /etc/passwd file?  Perhaps
:> as root, but not as any other UID, I would suspect.)

: The program can be written to make system calls directly, without using
: a library, or it can be statically linked with a minimal library.  The
: kernel *will* allow the program to run if there is no /etc/passwd file. 
: It will always be run as root, though it can then change its uid using a
: system call without referencing /etc/passwd.

:> I still maintain that there is a bit more to the core linux OS than
:> just a running kernel, given that the kernel on it's own is entirely
:> useless without at least a filesystem to mount as '/'.

: What difference does this make?  The file system support itself is part
: of the kernel anyway.

No, not the software that controls the filesystem, but the actual
filesystem itself - the blocks and inodes stored out on the
disk - are not part of the kernel but are part of the OS, for
without them you have no ability to run a program.  (or even boot
the kernel for that matter, since the kernel image itself is on
the filesystem.  {In theory you could write the kernel image to
"dumb" blocks on a partition that isn't formatted to a filesystem,
and then make a LILO entry that chains those blocks together as the
kernel image, but does anyone actually do that?) )

And that leads to another question:  Does "Another method that avoids
using foo could be used to get the OS to work, in theory", mean that
foo isn't part of the OS even if in practice foo is always used?

After all, in theory memory protection doesn't need to be in an OS,
if you don't care about security, and you don't mind that this makes
programs rather hard to debug, but does that mean it's not part
of the OS?  If in theory you could create a linux installation that
contains no filesystem on any device (not even burned on a chip),
would that mean filesystems are not part of the OS?