On 2006-01-19, Erik V. Smith <[EMAIL PROTECTED]> wrote: > If Matt, or anyone else very knowledgeable, would like to lead the way > with designing a devd, I will implement it. If not, I'll do my best.
To start off, I'm not one of the very knowledgeable, yet I have an idea of a "dynamic dev" solution which would be based on the unique (planned) feature set of Dfly. (Eventually, I wanted to make some kind of RFC about it, but the whole thing is not yet possible, so I decided on to wait; but with this discussion going on, why not to mention it now?) So: - Traditional devfs sucks because of too much mucking with implementing/debugging/maintaining yet another vfs, it has to be hooked deeply into the kernel, etc. (I think most people in this list would agree with this.) And if devfs woes, you get a panic. - Traditional devd sucks because it's too weak. There are certain events which just can't be caught. Typical unsatisfiable feature request is on-demand module loading, but there are many similar scenarios: create devices on the fly when they are looked up, spawn yet another copy of a "clonable" device like ptys, md devices, tun/tap devices... A hybrid solution can get the best of both worlds without the disadvantages. For this, we'll need userspace filesystems. That's the feature which will come but it's not yet here. Like in Solaris, have a dual device namespace: - /devices contains the real device files - /dev contains custom-tailored symlinks to /devices, that's intented for public use. Unlike Solaris, /devices would be a plain directory (under a devd's treatment), amd /dev would be mounted with a dedicated fs on it. The trick is that the dedicated fs would be a userspace fs, driven by a daemon -- the same daemon which does the usual devd stuff on /devices... Writing userspace fs's can and should be made easy and safe, so the maitainance horror of trad. devfs goes away. And userspace fs-es don't cause panics if they kick the bucket. The daemon could intercept any kind of device access in /dev, and according to a policy, do mknod or whatever in /devices, and return with the appropriate symlink to the requestor. This model doesn't impose any constraint on the kernel's way of handling devices, just requires an userspace interface by which exact device information can be queried (and of course, as I said, the userspace fs stuff). That is, if you are unsatisfied, you could go back where we are now simply by "umount /dev && rmdir /dev && mv /devices /dev". Regards, Csaba
