> It's a very bad way to expose kernel state, and the same problem the> original devfs had. A good kernel state filesystem is immutable to> changes from userspace, that is fully controlled by the kernel. The> problem with devfs and your new devfstmpfs is that you have both> userspace and the kernel manipulating the same object. Which for> example makes life time management impossible.

It's well defined. When the device goes away, the node is removed, inthe same way the sysfs device is removed, and if userspace hascreated/replaced the node, it has control over it and the kernel doesnot touch it anymore. There is no known problem with that and nodifference how udev works today on all common systems.If wanted, at the time you guys come up with a working union-mount, wecan make the kernel-maintained dev-filesystem read-only and mount atmpfs on-top of it. But we are not there at the moment.

> I also know who gladly killed it

And for good reason. The naming scheme was as wrong as it could be. Wehave a completely different situation today.

> just to re-introduce the same thing years later,

It's not the same at all. There is udev today, and a well-defined wayto work with /dev, synchronized across all distros. Nothing reallychanges with devtpmfs, it just gets simpler, has less races, and is alot more reliable.

It's a logical extension to sysfs, not much more. We create all thethings in /sys, why shouldn't we create the few nodes too, and makemany things much easier?