cowloop technology

[Csaba Henk]

On 2006-01-19, Erik V. Smith <erikvsmith at xxxxxxxxxxx> 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