On Sun, Jul 31, 2011 at 20:05, Greg KH <greg@xxxxxxxxx> wrote:
> On Sun, Jul 31, 2011 at 11:31:16AM -0500, William Hubbs wrote:
>>
>> 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?
>
> 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.
>> 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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
