the file system for /dev
All,
The setup section of the udev README mentions that /dev should get the devtmpfs file system, but it also says that udev can be run on a blank tmpfs as long as you create /dev/{null,kmsg,console}. Also, the requirements section never mentions CONFIG_DEVTMPFS.
So, I guess I'm attempting to figure out what is preferred. Is devtmpfs preferred for distros? What are reasons that someone might not want to use devtmpfs with udev?
William
Quoted 9 lines · William Hubbs
All,
The setup section of the udev README mentions that /dev should get the devtmpfs file system, but it also says that udev can be run on a blank tmpfs as long as you create
/dev/{null,kmsg,console}. Also, the requirements section never mentionsCONFIG_DEVTMPFS.So, I guess I'm attempting to figure out what is preferred. Is devtmpfs preferred for distros?
Yes.
Quoted 2 lines
What are reasons that someone might not want to use devtmpfs with udev?
They don't want to use it? I don't know, why not ask the distros that don't use it why they don't want it.
good luck,
greg k-h
Quoted 11 lines · Greg KH
Quoted 8 lines · William Hubbs
The setup section of the udev README mentions that /dev should get the devtmpfs file system, but it also says that udev can be run on a blank tmpfs as long as you create
/dev/{null,kmsg,console}. Also, the requirements section never mentionsCONFIG_DEVTMPFS.So, I guess I'm attempting to figure out what is preferred. Is devtmpfs preferred for distros?
Yes.
Right, it's the only way to avoid races when modules are loaded and the device nodes are expected to exist when modprobe returns, or when ioctl-like interfaces are used to create new devices. When the call return from the kernel, we can be sure the nodes are created. Only devtmpfs provides this synchronization-less behavior here, tmpfs always needs to be synchronized with the asynchronous udev actions.
Quoted 2 lines
Quoted 2 lines
What are reasons that someone might not want to use devtmpfs with udev?
Nothing really. In theory, it might be useful in container-like setups to be able to run udev on a plain tmpfs. I don't think that is used anywhere these days, it's surely not really tested anymore.
Such theoretic setups are the only reason the mknod() code is still in udev, it's not really needed anymore, and we could also just remove it and hard require devtmpfs, I guess.
Quoted 2 lines
They don't want to use it? Â I don't know, why not ask the distros that don't use it why they don't want it.
Without devtmpfs quite a few things will not work out-of-the-box as expected, and nobody really cares about these failure cases, because we all use devtmpfs these days.
Kay