So here’s the list of parts we need to build a working, useful Unix system:
init
a supervisor
a login program
a shell
a C library
Isn’t really more needed when it comes to Linux?
Using only that, you will have an empty /dev, as mknod isn’t part of the shell (not even talking about udev), and I think you get a kernel panic in such case.
On a side note, I’ve been working on a self-bootstrapping distro for quite a while, and I was stunned by the amount of programs needed to reach this goal (think gcc, yacc, perl, python, etc…)
Who creates them then? The kernel itself?
Take /dev/console for example. Wouldn’t it prevent the kernel to boot if it is not present?
AFAIK, udev does more than hotplugging, as it replaces what devfs used to do.
When a device driver registers new device, the kernel creates a node in devtmpfs. There is no need to manage it with udev in static configurations. Many embedded Linux systems never run udev. There’s been no practical hard requirement for mknod since 2.6.
Take /dev/console for example. Wouldn’t it prevent the kernel to boot if it is not present?
The kernel does not write to the console (or any other device) by opening a device node in the filesystem. The device driver already lives inside the kernel, there’s no need to go via the filesystem (it writes to the console well before the root filesystem is mounted). So no, it wouldn’t prevent the kernel from booting if /dev/console wasn’t present. (It might create a problem for early userspace, though IIRC even init will have handles to the console set up directly by the kernel).
I wonder to what extent a system would be usable with an empty /dev. Would a shell actually start without a TTY?
I was playing with containers the other day, and running mksh inside it required that I create a few nodes in $chroot/dev/ before being able to start it. Maybe other shells can work around that?
Containers share a kernel, which is already aware of the devices, on an isolated file system and process space where there is limited kernel introspection in this regard. Thus the rules are a little different.
I don’t know the specific details of various shells, but in theory I think it should be possible to have a shell that doesn’t try to open any devices. (It’s a pretty onerous restriction though; there’s not much you’ll be able to do in a system with no device nodes).
Isn’t really more needed when it comes to Linux? Using only that, you will have an empty /dev, as
mknodisn’t part of the shell (not even talking about udev), and I think you get a kernel panic in such case.On a side note, I’ve been working on a self-bootstrapping distro for quite a while, and I was stunned by the amount of programs needed to reach this goal (think gcc, yacc, perl, python, etc…)
defvs entries aren’t populated from the userspace for a while now, and udev isn’t a requirement unless you handle hotplug.
I thought systemd/udev populated /dev on modern systems
Indeed, devfs has been marked obsolete in 2003 in favor of udev:
https://lwn.net/Articles/44731/
Of course, you could just pre-create the device nodes, as was done before udev and devfs ;).
Slip of the pen, it’s devtmpfs.
https://lwn.net/Articles/330985/
See my sibling reply. Neither udev nor systemd are requirements for a usable system, Linux predates both by many years.
Who creates them then? The kernel itself? Take /dev/console for example. Wouldn’t it prevent the kernel to boot if it is not present? AFAIK, udev does more than hotplugging, as it replaces what devfs used to do.
When a device driver registers new device, the kernel creates a node in devtmpfs. There is no need to manage it with udev in static configurations. Many embedded Linux systems never run udev. There’s been no practical hard requirement for mknod since 2.6.
The kernel does not write to the console (or any other device) by opening a device node in the filesystem. The device driver already lives inside the kernel, there’s no need to go via the filesystem (it writes to the console well before the root filesystem is mounted). So no, it wouldn’t prevent the kernel from booting if /dev/console wasn’t present. (It might create a problem for early userspace, though IIRC even init will have handles to the console set up directly by the kernel).
This makes sense indeed, thanks for the reply!
I wonder to what extent a system would be usable with an empty /dev. Would a shell actually start without a TTY? I was playing with containers the other day, and running mksh inside it required that I create a few nodes in
$chroot/dev/before being able to start it. Maybe other shells can work around that?Containers share a kernel, which is already aware of the devices, on an isolated file system and process space where there is limited kernel introspection in this regard. Thus the rules are a little different.
I don’t know the specific details of various shells, but in theory I think it should be possible to have a shell that doesn’t try to open any devices. (It’s a pretty onerous restriction though; there’s not much you’ll be able to do in a system with no device nodes).
Though the fork children could always inherit standard output et al.
That’s what I was
implyingtrying to imply, yes.gosh, to do this on a BSD is essentially: clone the repo, change whatever you want and then type make world.
“Wanna write a Linux userland” scans better, I think
‘Wanna’ isn’t a word.